Re: [openstack-dev] Please stop reviewing code while asking questions

[Robert Collins]

On 25 April 2015 at 05:43, Ben Nemec  wrote:
> On 04/24/2015 07:11 AM, Russell Bryant wrote:
>> On 04/24/2015 07:21 AM, Amrith Kumar wrote:
>>> We had a hypothesis about why +0 was rarely used (never conclusively
>>> proved). Our hypothesis was that since Stackalytics didn't count +0's
>>> it led to an increased propensity to -1 something. It would be
>>> wonderful if we could try the experiment of giving credit for 0's and
>>> seeing if it changes behavior.
>>
>> I think this makes a lot of sense.  These stats really do drive
>> behavior.  I'd certainly be open to a patch to reviewstats [1] to count
>> +0 comments and I think it would be good for stackalytics to consider
>> the same.
>>
>> [1] http://git.openstack.org/cgit/openstack-infra/reviewstats
>>
>
> I actually looked at doing this a while ago, but unfortunately the json
> data we were getting from Gerrit didn't include no scores.  That may
> have been pre-Gerrit upgrade so it's possible it will have changed, but
> it's worth noting that we may just not have the ability to track this.

I believe we'll need to switch to the REST JSON API, which gertty uses
and gets comments -> some nontrivial refactoring implied, and I
shudder to think about the performance impact.

I've wanted to rewrite reviewstats for a while... this might be the trigger...

-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] Please stop reviewing code while asking questions

[Robert Collins]

On 25 April 2015 at 01:13, Zane Bitter  wrote:
> On 24/04/15 07:21, Amrith Kumar wrote:
>>
>> Julien,
>>
>> We had a similar discussion within Trove several months ago and agreed to
>> a convention that if you have a question, that should not warrant a -1
>> unless, as you indicate there's a strong reason to believe that the code is
>> wrong and the question is leading.
>
>
> +1. I'm kind of shocked that this even needed to be discussed, but well done
> :)
>
>> We discussed this at a mid-cycle and agreed to put our conventions in
>> CONTRIBUTING.rst[1].
>>
>> We had a hypothesis about why +0 was rarely used (never conclusively
>> proved). Our hypothesis was that since Stackalytics didn't count +0's it led
>> to an increased propensity to -1 something. It would be wonderful if we
>> could try the experiment of giving credit for 0's and seeing if it changes
>> behavior.
>
>
> IIRC the problem here is the Gerrit API - it doesn't count +0 as a 'review',
> so they just don't show up in any automated tools. (This isn't easily solved
> either, even assuming you're willing to modify Gerrit.)

The comments are definitely accessible over the new JSON API that
gertty uses, so we can solve this now, however fugly it might look in
reviewstats.


> Individualised closed-loop metrics *always* drive bad behaviour, because
> they're necessarily only a sample of the behaviour we care about and to the
> extent that sample is representative of the whole, it can only remain so in
> the open-loop case. So we can, and should, tweak metrics to reduce bad
> behaviour and encourage good behaviour, but we shouldn't kid ourselves that
> we can eliminate unintended consequences - we can only exchange them for
> _different_ unintended consequences.
>
> This is an open community, so we can't (and shouldn't want to) prevent
> people from publishing stats. The best case is that we use them only to
> inform us how we're doing in the aggregate, and discourage companies in
> particular from attaching individual incentives to game the metrics. Members
> of the TC, at least, (I don't know that there was ever an official edict or
> anything) have expressed this in the past, and I think it's one of those
> things that requires vigilance and periodic reminders.

We could publish a document of common bad metrics and why we as a
community reject them. That might give folk inside contributing
companies some additional support in convincing metric-users not to
look at some of the metrics out there.

-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] Please stop reviewing code while asking questions

[Robert Collins]

On 25 April 2015 at 00:11, Russell Bryant  wrote:
> On 04/24/2015 07:21 AM, Amrith Kumar wrote:
>> We had a hypothesis about why +0 was rarely used (never conclusively
>> proved). Our hypothesis was that since Stackalytics didn't count +0's
>> it led to an increased propensity to -1 something. It would be
>> wonderful if we could try the experiment of giving credit for 0's and
>> seeing if it changes behavior.
>
> I think this makes a lot of sense.  These stats really do drive
> behavior.  I'd certainly be open to a patch to reviewstats [1] to count
> +0 comments and I think it would be good for stackalytics to consider
> the same.
>
> [1] http://git.openstack.org/cgit/openstack-infra/reviewstats

IIRC the limit was gerrit, not reviewstats, and we've not revisited
since the gerrit upgrade.

-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] [Glance] Pre-Liberty Virtual Mini Summit

[Nikhil Komawar]

Hello all,

Glance community is planning to conduct a Pre-Liberty-Summit video conferencing 
event over 2 days on Tuesday May 12th and Wednesday May 13th for everyone to 
discuss topics that are or are not going to be discussed at the main event. It 
will help everyone be prepared at Vancouver and be able to make the most out of 
such an extraordinary event. You are encouraged to propose topics. Since, we 
have limited slots, please try to do that as soon as possible.

The tentative schedule and sign up list is available at:
https://etherpad.openstack.org/p/liberty-glance-virtual-mini-summit
  
We are looking to finalize the schedule over the next few days and it will be 
available on the same etherpad. Please let me know if you have any questions. 

Thanks,
 -Nikhil

__
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] [Glance] Liberty Summit Topics

[Nikhil Komawar]

The summit planning etherpad [0] is up and available for discussing topics 
related to Glance during the Fishbowl and Work sessions.

The agenda for the Friday sprint will be kept open. If you've more suggestions 
or need input on a topic which you would like to include as a part of the 
sessions, please ping me (nikhil_k) on IRC or attend the upcoming Glance 
meetings [1].

For more information on sessions related to other projects including 
cross-project sessions please visit the summit planning wiki page [2].


[0] https://etherpad.openstack.org/p/liberty-glance-summit-topics

[1] https://wiki.openstack.org/wiki/Meetings/Glance

[2] https://wiki.openstack.org/wiki/Design_Summit/Planning


Thanks,
-Nikhil
__
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] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
> If we've reached the point where we're arguing about naming, dos this mean
>> we've built consensus on the "yes, it makes sense for these to live under
>> Neutron" argument?
>>
>
>
I think we are in agreement that these projects need to find a more obvious
home, they feel somewhat orphan otherwise. Most of them are extensions or
plugins to Neutron and since they cannot stand alone, it makes sense to
have them associated with it. As far as I am concerned I think the matter
is about the inclusion methodology as well as the timing.

Cheers,
Armando
__
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] Please stop reviewing code while asking questions

[Kai Qiang Wu]

+1 about Dan's comments.


1. We should not discourage all cases for -1 for questions. Because it
often leads more discussion about the code issue, it is helpful for such
case.

Of course, it is diffcult to find a balance point, what can -1, what can 0.
I don't think 0 in gerrit works well, because sometimes authors not care
about that.



2. Also, for typos in comments and message, -1 makes sense too.
Because 0 in gerrit means no need to improve the message and everything is
good. It can lead many bad cases for cores, and non-cores. It means it
doesn't matter if spell right or wrong.






Best Wishes,


Follow your heart. You are miracle!



From:   Dan Smith 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/24/2015 10:48 PM
Subject:Re: [openstack-dev] Please stop reviewing code while asking
questions



> In defense of those of us asking questions, I'll just point out
> that as a core reviewer I need to be sure I understand the intent
> and wide-ranging ramifications of patches as I review them.  Especially
> in the Oslo code, what appears to be a small local change can have
> unintended consequences when the library gets out into the applications.
>
> I will often ask questions like, "what is going to happen in X
> situation if we change this default" or "how does this change in
> behavior affect the case where Y happens, which isn't well tested
> in our unit tests." If those details aren't made clear by the commit
> message and comments in the code, I consider that a good reason to
> include a -1 with a request for the author to provide more detail.
> Often these are cases I'm not intimately familiar with, so I ask a
> question rather than saying outright that I think something is
> broken because I expect to learn from the answer but I still have
> doubts that I want to indicate with the -1.
>
> Most of the time the author has thought about the issues and worked
> out a reason they are not a problem, but they haven't explained
> that anywhere. On the other hand, it is frequently the case that
> someone *hasn't* understood why a change might be bad and the
> question ends up leading to more research and discussion.

Right, and -1 makes the comment much more visible to both other cores
and the reviewer. Questions which rightly point out something which
would lead to what the OP considers a legit -1 can *easily* get missed
in the wash of review comments on a bug.

If you leave a -1 for a question and never come back to drop it when the
answer is provided, then that's bad and you should stop doing that.
However, I'm really concerned about the suggestion to not -1 for
questions in general because of the visibility we lose. I also worry
that more non-core people will feel even less likely to -1 a patch for
something they feel is just their failing to understand, when in fact
it's valuable feedback that the code is obscure.

As a core, I don't exclude all reviews with a -1, and doing so is pretty
dangerous behavior, IMHO.

I'm not sure if the concern of -1s for questions is over dropping the
review out of the hitlist for cores, or if it's about hurting the
feelings of the submitter. I'm not in favor of discouraging -1s for
either problem.

--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] [nova] Port Nova to Python 3

[Mike Bayer]

On 4/24/15 4:18 PM, Sean Toner wrote:

On Friday, April 24, 2015 11:20:03 AM Joshua Harlow wrote:

Sean Toner wrote:

If written to use python 3, I hope it will use all the new features
of python 3.4 moving forward.

For example, argument annotations, coroutines, asyncio, etc.  At my
last workplace, we tried to make our project python2 and 3
compatible (ie, you could run it under 2.7 or 3.3+) but this was
the worst of all worlds.

Likely the reality of things is different from the desires :)

I know we'd all love to just do the above (or some of us would like
to), but we also need to think about what shiny new features really
make the quality of nova any better (IMHO some of the above really
don't change much for the better...)

Out of curiosity why was your experience 'the worst of all worlds'?

Like I answered to Victor, it means that you don't get the nice new
features only available in python3 (argument annotations, coroutines,
namespace packaging, etc) while at the same time dealing with the
inconsistencies between python2 and 3 code.


These are all very new features who's acceptance and maturity is yet to 
happen.  Even if these things were available in Python 2 right now, we 
should be very hesitant to sprint down new roads; these aren't assured 
to be winning features.   Also, I work in the realm of Py2k/3k 
cross-compatible code exclusively for several years now and I think 
you're overstating its difficulty, as did the core Python developers 
originally when they made us all believe we'd need a code rewriting tool 
in order to use Python 3, which then led us way down the wrong road 
which we all had to backtrack from.




For example, having to manage some imports, dealing with some functions
now returning bytes instead of str, and all kinds of other fun :)

Here's one example of having to change an import:

try:
 from urllib.request import urlopen
 from urllib.parse import urlparse as urlparse
except ImportError:
 from urllib2 import urlopen
 from urlparse import urlparse
compatibility layers like six handle issues like these pretty simply, 
plus I thought we had some requests-like compatibility layer in place in 
any case.





I also had some code that created a subprocess.Popen object to execute
some command.

i would have used the multiprocessing library instead.



  Some commands output got returned as a regular str, and
some others got returned as bytes.  So I wound up in my class creating a
defensive decorator function that called

if  isinstance(output, bytes):
   return output.decode()

And that's just 2 that popped into my head :)


How would not being Py2k compatible help with dealing with functions 
that randomly return either bytes or strings?





And it was frustrating
having to do extra work, and yet not be able to partake of all the
python3 goodies.

But, if this is a stepping stone to a pure python3 environment even if
that takes until python2 to EOL, I'm ok with that :)


Regards,
Sean

On Friday, April 24, 2015 04:34:48 AM Victor Stinner wrote:

Hi,

Porting OpenStack applications during the Liberty Cycle was
discussed
last days in the thread "[oslo] eventlet 0.17.3 is now fully Python
3
compatible".

I wrote a spec to port Nova to Python 3:
 https://review.openstack.org/#/c/176868/

I mentioned the 2 other Python 3 specs for Neutron and Heat.

You can reply to this email, or comment the review, if you want to
discuss Python 3 in Nova, or if you have any question related to
Python 3.

See also the Python 3 wiki page:
 https://wiki.openstack.org/wiki/Python3

Thanks,
Victor

___
___  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 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 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] [Zaqar] Call for adoption (or exclusion?)

[Zane Bitter]

On 24/04/15 20:00, Joe Gordon wrote:



On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote:

Notification might be a good way to integrate with nova. Individual
tenants might want to do things as vm's come up/down, etc. Right
now, you need a privileged pipe into rabbit. Forwarding them to
Zaqar, per tenant queue's could solve the problem.


Right now you can poll the nova API. Or tenants can use any number of
monitoring tools.  How does zaqar better then the alternatives?


So, a couple of points about that:

 1) Polling sucks.
 2) If a bunch of things are going to get polled, at least collect them 
together so there is *one* thing to optimise for massive polling load. 
(Zaqar is this thing - you have to poll it too atm.)
 3) Long-polling and WebSockets suck a lot less than polling. If you 
already collected all the polling in one place, it's really easy to make 
the switch as soon as you implement them in that one place.
 4) If you don't have a common place to poll, then you can't use the 
events as triggers for other services in OpenStack (without writing 
custom polling code for every endpoint in every API - which is pretty 
much what Heat does now, but that work doesn't extend automatically to 
Mistral, Congress, &c. in the way that Zaqar notifications could.)


Also, APIs tend to only return the current status. You could miss events 
if you just poll the API, whereas if the events are dispatched to a 
durable queue and you just poll the queue for events, that problem goes 
away.



FWIW, I think there are some really neat use cases for amazon SQS, that
presumably Zaqar would fit as well. Cases such as
https://aws.amazon.com/articles/1464


Bingo, this is where it starts to get really interesting.

cheers,
Zane.



Thanks,
Kevin

*From:* Joe Gordon [joe.gord...@gmail.com
]
*Sent:* Friday, April 24, 2015 4:02 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco mailto:fla...@redhat.com>> wrote:

Greetings,

I'd like my first action as Zaqar's PTL to be based on
reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and
community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward
to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since


I get integration with Horizon etc. But to use the SQS/SNS analogy
how would say Nova integrate with Zaqar?

Icehouse's - we've been collecting feedback from the community.
We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had
successes, as
a project and as a team. Nevertheless, we've got to the point
where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage
of the
workshop slots and invite people from other projects to help
us/guide
us through a hacking session on their projects so we can help
with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the
project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises
of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco


_

[openstack-dev] [pbr] support for 'python setup.py install'

[Robert Collins]

In our pbr integration tests we ensure that 'python setup.py install'
works, as well as ensuring that 'pip install' works. But see
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015525.html
- for the last 18 months in pbr we've treated complains that setup.py
install fails as a reason to say 'use pip install .'.

I'd like to make that a little more official:
 - put it in our docs
 - stop testing python setup.py install.

This would relegate setup.py to building, not installation, which is
what its intended to be these days.

Thoughts?

-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] [Zaqar] Call for adoption (or exclusion?)

[Zane Bitter]

On 24/04/15 19:02, Joe Gordon wrote:



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco mailto:fla...@redhat.com>> wrote:

Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since


I get integration with Horizon etc. But to use the SQS/SNS analogy how
would say Nova integrate with Zaqar?


Speaking very generally, anything where it makes sense for Nova to tell 
the user - or, more importantly, the application - when something is 
happening. The cloud can't afford to be making synchronous calls to the 
client-side, and applications may not be able to afford missing the 
notifications, so a reliable, asynchronous transport like Zaqar is a 
good candidate.


So examples might be:
 - Hey, your resize is done
 - Hey, your [re]build is done
 - Hey, your VM rebooted
 - Hey, your VM disappeared

Now, this is not to presuppose that having Nova put messages directly 
into Zaqar is the correct design. It may be that it's better to have 
some other service (Ceilometer?) collect some or all of those 
notifications and handle putting them into Zaqar (though the reliability 
would be a concern). Certainly EC2 seems to funnel all this stuff to 
CloudWatch, although other services like S3, CloudFormation & Auto 
Scaling deliver notifications to SNS directly. There is some integration 
work either way though, to produce the notification.


Obviously there's less integration to do for a project like Nova that 
only produces notifications than there would be for those that could 
actually consume notifications. Heat would certainly like to use these 
notifications to reduce the amount of polling we do of the APIs (and 
ditch it altogether if reliability is guaranteed). But if we can get 
both ends integrated then the *user* can start doing really interesting 
things like:


 - Hey Zaqar, give me a new queue/topic/whatever
 - Hey Mistral, run this workflow when you see a message on this topic
 - Hey Nova, send a message to this topic whenever my VM reboots

Bam, user-defined workflow triggered on VM reboot. (Super easy to set up 
in a Heat template BTW ;)


It gets even cooler when there are multiple producers and consumers: 
imagine that Ceilometer alarms and all other kinds of notifications in 
OpenStack are produced this way, and that SNS-style notifications, Heat 
autoscaling events and Mistral workflows can all be triggered by them. 
And of course if the logic available in the workflow isn't sufficient, 
the user can always insert their own conditioning logic running in a VM 
(future: container), since the flow is through a user-facing messaging 
system.


I wrote a blog post earlier today about why all this is needed:

http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack

tl;dr: many applications being written now and even more in the future 
will expect to be able to interact with their own infrastructure and 
will go to proprietary clouds if we don't provide an open source 
alternative.


cheers,
Zane.


Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
or

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M  wrote:

>  Notification might be a good way to integrate with nova. Individual
> tenants might want to do things as vm's come up/down, etc. Right now, you
> need a privileged pipe into rabbit. Forwarding them to Zaqar, per tenant
> queue's could solve the problem.
>
>
Right now you can poll the nova API. Or tenants can use any number of
monitoring tools.  How does zaqar better then the alternatives?


FWIW, I think there are some really neat use cases for amazon SQS, that
presumably Zaqar would fit as well. Cases such as
https://aws.amazon.com/articles/1464



> Thanks,
> Kevin
>  --
> *From:* Joe Gordon [joe.gord...@gmail.com]
> *Sent:* Friday, April 24, 2015 4:02 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
>
>
>
> On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  wrote:
>
>> Greetings,
>>
>> I'd like my first action as Zaqar's PTL to be based on reflections and
>> transparency with regards to what our past has been, to what our
>> present is and to what our future could be as a project and community.
>> Therefore, I'm sending this call for adoption and support before
>> taking other actions (also mentioned below).
>>
>> The summit is very close and the Zaqar team is looking forward to it.
>>
>> The upcoming summit represents an important opportunity for Zaqar to
>> integrate with other projects. In the previous summits - since
>>
>
>  I get integration with Horizon etc. But to use the SQS/SNS analogy how
> would say Nova integrate with Zaqar?
>
>
>> Icehouse's - we've been collecting feedback from the community. We've
>> worked on addressing the many use-cases, we've worked on addressing
>> the concerns raised by the community and we've also kept moving
>> towards reaching the project's goals.
>>
>> As you all know, the project has gone through many ups and downs.
>> We've had some "failures" in the past and we've also had successes, as
>> a project and as a team. Nevertheless, we've got to the point where it
>> doesn't make much sense to keep pushing new features to the project
>> until it gains adoption. Therefore, I'd like to take advantage of the
>> workshop slots and invite people from other projects to help us/guide
>> us through a hacking session on their projects so we can help with the
>> adoption. The current adoption of Zaqar consist in:
>>
>> - 1 company reachingunning it in production
>> - 1 planning to do it soon
>> - RDO support
>>
>> Unfortunately, the above is certainly not enough for a project to
>> succeed and it makes the time and effort spent on the project not
>> worth it. It's been more than 2 years since we kicked the project off
>> and it's time for it to show some results. The current problem seems
>> to be that many people want the project but no one wants to be the
>> first in adopting Zaqar (which kind of invalidates the premises of the
>> "Big tent").
>>
>> In summary, this is a call for adoption before we call it a nice
>> adventure and ask for the project to be excluded from the OpenStack
>> organization based on the lack of adoption and contributions.
>>
>> If you think it's worth it, speak up. Either way, thanks for the
>> support and for reading thus far.
>>
>> On behalf of the Zaqar team,
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __
>> 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 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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Morgan Fainberg]

Keystone client version of the middleware is deprecated and only receiving 
minimal security updates. This code is unlikely to see any real changes due it 
its deprecation and frozen state. 

We are evaluating how to remove it from the client lib. 

Sent via mobile

> On Apr 24, 2015, at 00:27, Victor Stinner  wrote:
> 
> Hi,
> 
>> The part of keystoneclient that uses the memcached client was deprecated in 
>> Juno (as it was moved to the keystonemiddleware repo),
> 
> Oh, I was not aware of the keystonemiddleware project. I see that Nova uses 
> it for example.
> 
> 
>> so I think we can remove it now.
> 
> Do someone know if the middleware of keystoneclient is still used?
> 
> 
>> You might want to patch it out  of your keystoneclient package if you know 
>> everything's using the auth_token middleware from keystonemiddleware.
> 
> What should we do with the following bug?
> 
>   "memcache tests are skipped on python 3"
>   https://bugs.launchpad.net/python-keystoneclient/+bug/1447731
> 
> I also wrote a patch for keystoneclient:
> 
>   "Enable test_auth_token_middleware() on Python 2"
>   https://review.openstack.org/#/c/176778/
> 
> If the keystoneclient middleware is removed, we can simply close the bug and 
> abandon the change.
> 
> Victor
> 
> __
> 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] [Zaqar] Call for adoption (or exclusion?)

[Fox, Kevin M]

Notification might be a good way to integrate with nova. Individual tenants 
might want to do things as vm's come up/down, etc. Right now, you need a 
privileged pipe into rabbit. Forwarding them to Zaqar, per tenant queue's could 
solve the problem.

Thanks,
Kevin

From: Joe Gordon [joe.gord...@gmail.com]
Sent: Friday, April 24, 2015 4:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)



On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco 
mailto:fla...@redhat.com>> wrote:
Greetings,

I'd like my first action as Zaqar's PTL to be based on reflections and
transparency with regards to what our past has been, to what our
present is and to what our future could be as a project and community.
Therefore, I'm sending this call for adoption and support before
taking other actions (also mentioned below).

The summit is very close and the Zaqar team is looking forward to it.

The upcoming summit represents an important opportunity for Zaqar to
integrate with other projects. In the previous summits - since

I get integration with Horizon etc. But to use the SQS/SNS analogy how would 
say Nova integrate with Zaqar?

Icehouse's - we've been collecting feedback from the community. We've
worked on addressing the many use-cases, we've worked on addressing
the concerns raised by the community and we've also kept moving
towards reaching the project's goals.

As you all know, the project has gone through many ups and downs.
We've had some "failures" in the past and we've also had successes, as
a project and as a team. Nevertheless, we've got to the point where it
doesn't make much sense to keep pushing new features to the project
until it gains adoption. Therefore, I'd like to take advantage of the
workshop slots and invite people from other projects to help us/guide
us through a hacking session on their projects so we can help with the
adoption. The current adoption of Zaqar consist in:

- 1 company reachingunning it in production
- 1 planning to do it soon
- RDO support

Unfortunately, the above is certainly not enough for a project to
succeed and it makes the time and effort spent on the project not
worth it. It's been more than 2 years since we kicked the project off
and it's time for it to show some results. The current problem seems
to be that many people want the project but no one wants to be the
first in adopting Zaqar (which kind of invalidates the premises of the
"Big tent").

In summary, this is a call for adoption before we call it a nice
adventure and ask for the project to be excluded from the OpenStack
organization based on the lack of adoption and contributions.

If you think it's worth it, speak up. Either way, thanks for the
support and for reading thus far.

On behalf of the Zaqar team,
Flavio

--
@flaper87
Flavio Percoco

__
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] [nova] Port Nova to Python 3

[Clint Byrum]

Excerpts from Sean Toner's message of 2015-04-24 05:38:42 -0700:
> If written to use python 3, I hope it will use all the new features of 
> python 3.4 moving forward.
> 
> For example, argument annotations, coroutines, asyncio, etc.  At my last
> workplace, we tried to make our project python2 and 3 compatible (ie, 
> you could run it under 2.7 or 3.3+) but this was the worst of all 
> worlds.
> 

Sean, this is a very developer-centric way of thinking.

Our operators will likely roll out python3 interpreters at a different
cadence than they roll out releases of OpenStack.

The best of both worlds is working perfectly fine on python 2.7 and
3.4+ until 2.7 is eradicated entirely, so that our operators can manage
change effectively.

The reason for this port is as much because 2.7 has an EOL that is
approximately 5 years away as anything else. If we are not on top of
this, OpenStack will be dependent on dead software rapidly. It has taken
2+ years to get this far with effort happening on the edges. I suspect it
will take another cycle before we start turning on gates, and then another
2 cycles before we're comfortable telling people to run OpenStack on 3.x.

So, we have to be patient with the new shiny, but we have to be very
_impatient_ with broken things.

__
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] [Zaqar] Call for adoption (or exclusion?)

[Joe Gordon]

On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco  wrote:

> Greetings,
>
> I'd like my first action as Zaqar's PTL to be based on reflections and
> transparency with regards to what our past has been, to what our
> present is and to what our future could be as a project and community.
> Therefore, I'm sending this call for adoption and support before
> taking other actions (also mentioned below).
>
> The summit is very close and the Zaqar team is looking forward to it.
>
> The upcoming summit represents an important opportunity for Zaqar to
> integrate with other projects. In the previous summits - since
>

I get integration with Horizon etc. But to use the SQS/SNS analogy how
would say Nova integrate with Zaqar?


> Icehouse's - we've been collecting feedback from the community. We've
> worked on addressing the many use-cases, we've worked on addressing
> the concerns raised by the community and we've also kept moving
> towards reaching the project's goals.
>
> As you all know, the project has gone through many ups and downs.
> We've had some "failures" in the past and we've also had successes, as
> a project and as a team. Nevertheless, we've got to the point where it
> doesn't make much sense to keep pushing new features to the project
> until it gains adoption. Therefore, I'd like to take advantage of the
> workshop slots and invite people from other projects to help us/guide
> us through a hacking session on their projects so we can help with the
> adoption. The current adoption of Zaqar consist in:
>
> - 1 company reachingunning it in production
> - 1 planning to do it soon
> - RDO support
>
> Unfortunately, the above is certainly not enough for a project to
> succeed and it makes the time and effort spent on the project not
> worth it. It's been more than 2 years since we kicked the project off
> and it's time for it to show some results. The current problem seems
> to be that many people want the project but no one wants to be the
> first in adopting Zaqar (which kind of invalidates the premises of the
> "Big tent").
>
> In summary, this is a call for adoption before we call it a nice
> adventure and ask for the project to be excluded from the OpenStack
> organization based on the lack of adoption and contributions.
>
> If you think it's worth it, speak up. Either way, thanks for the
> support and for reading thus far.
>
> On behalf of the Zaqar team,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Eichberger, German]

Hi Brant,

Sorry, for being confusing earlier. We have operations an 
administrator/operator is performing on behalf of a user, e.g. “Create 
Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id 
and are wondering how to make the operation more robust with kesyone’s help.

Thanks,
German

From: Brant Knudson [mailto:b...@acm.org]
Sent: Friday, April 24, 2015 11:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate 
teanant-id for admin operation



On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German 
mailto:german.eichber...@hp.com>> wrote:
All,

Following up from the last Neutron meeting:

If Neutron is performing an operation as an admin on behalf of a user that 
user's tenant-id (or project-id) isn't validated - in particular an admin can 
mistype and create object on behalf of non existent users. I am wondering how 
other projects (e.g. Nova) deal with that and if there is some API support in 
keystone to save us a round trip (e.g. authenticate admin + validate additional 
user-id).

Not to long ago we got support in the auth_token middleware for a "service" 
token in addition to the user's token. The user token is sent in the 
x-auth-token header and the service token is sent in the x-service-token, and 
then fields from both tokens are available to the application (e.g., the user 
project is in HTTP_X_PROJECT_ID and the service token roles are in 
HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the 
server for the operation that required the service token to have the 'service' 
role, and what neutron could do is send the original user token in x-auth-token 
and send its own token as the service token. This seems to be what you're 
asking for here.

- Brant

Thanks,
German

__
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] Question for the TC candidates

[Monty Taylor]

On 04/24/2015 06:28 PM, David Medberry wrote:
> On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent  wrote:
> 
>>
>> What can and should the TC at large, and you specifically, do to ensure
>> quality improves for the developers, end-users and operators of
>> OpenStack as a full system, both as a project being developed and a
>> product being used?
> 
> 
> Hello Chris et al,
> 
> OpenStack quality will improve for the operators with a strong operator
> voice that helps focus developers and the overall technical focus on usage.
> OpenStack quality improves for developers in other ways: by hearing from
> end users and operators they can in part anticipate (or respond more
> quickly) to issues that will otherwise become truly raging hotspots (crises
> if you will.)
> 
> The other way to directly improve quality for OpenStack Devs is to improve
> test coverage and gate checks on more "production-like" systems. As an
> operator and advocate, I can persuade or motivate other operators to offer
> up resources (people as well as systems) to aid in this area of improvement.
> 
> These are indeed new times with operators playing a very critical role in
> OpenStack.

As a follow up to this thought - we _may_ be in a place over the next
cycle where Infra would be in a position to accept systems from
operators or others. Up until now we've only been in a position really
to deal with public clouds - but we're taking a stab at something new
and if it works out, it should open the door to taking advantage of
offers like this - which I agree will be a good thing for the project.


__
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] Question for the TC candidates

[David Medberry]

On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent  wrote:

>
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?


Hello Chris et al,

OpenStack quality will improve for the operators with a strong operator
voice that helps focus developers and the overall technical focus on usage.
OpenStack quality improves for developers in other ways: by hearing from
end users and operators they can in part anticipate (or respond more
quickly) to issues that will otherwise become truly raging hotspots (crises
if you will.)

The other way to directly improve quality for OpenStack Devs is to improve
test coverage and gate checks on more "production-like" systems. As an
operator and advocate, I can persuade or motivate other operators to offer
up resources (people as well as systems) to aid in this area of improvement.

These are indeed new times with operators playing a very critical role in
OpenStack.
__
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] [magnum] New fedora 21 Atomic images available for testing

[Steven Dake (stdake)]

From: , Motohiro mailto:yuany...@oeilvert.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, April 24, 2015 at 3:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] New fedora 21 Atomic images available for 
testing

Hi Madhuri,

I can’t also boot a vm with new image from.
But I can boot a vm using compressed image 
(fedora-21-atomic-3.qcow2.xz)
when decompress it by hand.

Regards,
-yuanying

Folks,

Just a notice you will need this review and all of its 3 parent patches:
https://review.openstack.org/#/c/177058/

Andrew has confirmed this image works – so Madhuri you should be unblocked once 
we get two +2’s on the reviews.



--
OTSUKA, Motohiro
Sent with Sparrow


On Friday, April 24, 2015 at 17:03, Madhuri Rai wrote:

Hi Steve,

I tried to boot a vm with the new image from. But it doesn't work.
The vm state was ACTIVE but I can't ping or ssh to the vm.

If anyone has tested it, please let me know.

Also I would request folks to test the image so that we can pass it as we need 
this image for Kubernetes Client.

Regards,
Madhuri


On Fri, Apr 24, 2015 at 2:00 PM, Madhuri Rai 
mailto:madhuri.ra...@gmail.com>> wrote:
Hi Steve,

Thank you for working on this.

It will be really good for us to remove dependency on external projects.

Regards,
Madhuri

On Fri, Apr 24, 2015 at 8:27 AM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Hi folks,

I have spent the last couple of days trying to bring some sanity to the image 
building process for Magnum.

I have found a tool which the Atomic upstream produces which allows a simple 
repeatable building process for Fedora Atomic images using any upstream repos 
of our choosing.

I put in a kubernetes 0.15 COPR repo in this build.  Please test and get back 
to me either on irc or the ML.

The image is available for download from here:
https://fedorapeople.org/groups/magnum/fedora-21-atomic-3.qcow2.xz

Regards,
-steve


__
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 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] [tempest][nova][cinder] Tests that try to detach volumes in use

[Joe Gordon]

On Fri, Apr 24, 2015 at 8:40 AM, Peter Penchev 
wrote:

> Hi,
>
> There are a couple of Tempest volume tests, like
> test_rescued_vm_detach_volume or test_list_get_volume_attachments,
> that either sometimes[0] or always attempt to detach a volume from a
> running instance while the instance could still be keeping it open.
> Unfortunately, this is not completely compatible with the StorPool
> distributed storage driver - in a StorPool cluster, a volume may only
> be detached from a client host (the Nova hypervisor) if there are no
> processes running on the host (e.g. qemu) that keep the volume open.
> This came about as a result of a series of Linux kernel crashes that
> we observed during our testing when a volume containing a filesystem
> was detached while the kernel's filesystem driver didn't expect it to.
>
> Right now, our driver for attaching StorPool volumes (defined in
> Cinder) to Nova instances (proposed in
>
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/libvirt-storpool-volume-attach.html
> yet didn't get enough +1/+2's in time for Kilo RC2) tries to detach
> the volume, then waits for a couple of seconds, hoping that any
> processes would have been notified to let it go, then tries again,
> then fails.  Of course, StorPool has a "force detach" option that
> could be used in that case; the problem there is that it might indeed
> lead to some trouble for the instances that will have the volume
> pulled out from under their tiny instance legs.  This could go in the
> "let the operator handle it" category - if we're detaching a volume,
> this supposedly means that the filesystem has already been unmounted
> within the instance... is this a sensible approach?  Should we teach
> our driver to forcibly detach the volume if the second polite attempt
> still fails?
>
>
IMHO, the number one thing to keep in mind when answering this is to keep
the user experience backend agnostic. A user should never have to know what
driver a cloud is using or be forced do do something differently because of
it.

So if the other standard is to allow detaching volumes in use in a way that
doesn't lead to trouble for the instances using the volume, your driver
should do that. If the standard is doing this can lead to trouble for
instances but it is still allowed then adding a forcible detach is
sufficient.



> G'luck,
> Peter
>
> [0] The "sometimes" part: it seems that in some tests, like
> test_list_get_volume_attachments, the order of the "detach volume" and
> "stop the running instance" actions is random, dependent on the order
> in which the Python test framework will execute the cleanup handlers.
> Of course, it might be that I'm misunderstanding something and it is
> completely deterministic and there is another issue at hand...
>
> __
> 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] [Nova] Add config option for real deletes instead of soft-deletes

[Joe Gordon]

On Tue, Apr 21, 2015 at 2:42 PM, Artom Lifshitz  wrote:

> Hello,
>
> I'd like to gauge acceptance of introducing a feature that would give
> operators
> a config option to perform real database deletes instead of soft deletes.
>
> There's definitely a need for *something* that cleans up the database.
> There
> have been a few attempts at a DB purge engine [1][2][3][4][5], and
> archiving to
> shadow tables has been merged [6] (though that currently has some issues
> [7]).
>
> DB archiving notwithstanding, the general response to operators when they
> mention the database becoming too big seems to be "DIY cleanup."
>
> I would like to propose a different approach: add a config option that
> turns
> soft-deletes into real deletes, and start telling operators "if you turn
> this
> on, it's DIY backups."
>
> Would something like that be acceptable and feasible? I'm ready to put in
> the
> work to implement this, however searching the mailing list indicates that
> it
> would be somewhere between non trivial and impossible [8]. Before I start,
> I
> would like some confidence that it's closer to the former than the latter
> :)
>

Acceptable as a deployer option: Yes
Feasible for all tables: Maybe.  The first steps would be:

1) Make a list of all the times we read soft deleted data and note which
tables they impact.
2) Determine if making soft delete optional on the tables impacted by
read_deleted=True, is useful. If so that would be a an easy win.
3) Figure out how to remove the read_deleted=True where used.


> Cheers!
>
> [1] https://blueprints.launchpad.net/nova/+spec/db-purge-engine
> [2] https://blueprints.launchpad.net/nova/+spec/db-purge2
> [3] https://blueprints.launchpad.net/nova/+spec/remove-db-archiving
> [4] https://blueprints.launchpad.net/nova/+spec/database-purge
> [5] https://blueprints.launchpad.net/nova/+spec/db-archiving
> [6] https://review.openstack.org/#/c/18493/
> [7] https://review.openstack.org/#/c/109201/
> [8]
> http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html
>
> __
> 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] [Nova] Reviewers please watch the check-tempest-dsvm-cells job now

[Sylvain Bauza]

Le 24/04/2015 23:19, Matt Riedemann a écrit :



On 4/21/2015 2:00 PM, Andrew Laski wrote:

It's been a long road but due to the hard work of bauzas and melwitt the
cells Tempest check job should now be green for changes that don't break
cells.  The job has been red for a long time so it's likely that people
don't think about it much.  I would ask that until we can get the
confidence to make it voting please take notice when it's red and
investigate or bring it to the attention of one of us in 
#openstack-nova.


__ 


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



I opened a couple of new bugs today since I had a cells job failure in 
a change that wasn't related to cells (was just adding some debug 
logging somewhere else).


1. https://bugs.launchpad.net/nova/+bug/1448316

That looks like a legit race failure in the cells job only.


As it is related to an instance destroy method in a negative patch, I 
think it's related to the race condition we discovered and that Andrew 
is trying to fix in https://review.openstack.org/#/c/177356/


More to investigate tho.



2. https://bugs.launchpad.net/nova/+bug/1448302

This is more cosmetic than anything, it doesn't appear to be related 
to anything functionally breaking.  We should get the trace cleaned up 
though since it makes debugging the cells job failures harder.




Again, we need to check if all of that is not just due to the race 
condition I said above.


-Sylvain



__
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] Question for the TC candidates

[Maru Newby]

> On Apr 23, 2015, at 9:14 AM, Chris Dent  wrote:
> 
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?
> 

I have strong opinions about how we can improve quality.  I stated some of them
in my candidate email.  I think we have a more pressing concern, though. How do
we ensure that our TC is capable of effecting the change we require?

Our TC's primary mission used to be defining what OpenStack was and was not.
The move to a 'big tent' model reduced the need to focus on that issue, and now
our TC needs to direct its attention to improving our community and the software
it delivers.  This new mission changes the game, because top-down direction is
not going to work.  Without direct authority to make change happen, how can the
TC hope to deliver?

Indirect authority.  13 people of influence, with on-the-ground support
developed and maintained at the project level, pulling in the same direction.
That's the real power of the TC.  And that's the power we're going to use to
effect real change.

This power is created by each TC member doing the hard work of engaging.  It's
writing, testing, debugging and documenting our software.  It's conversations
with developers, users, distros, and operators.  It's developing an emotional
connection - empathizing - with their constituents as they face the frustration
caused by our community and software.  It's making a difference so that their
opinion is respected.  This is the way things work in the individual projects,
and our TC should differ only in the scale of the problems it tackles.

This reinforces the idea, as has been suggested by other candidates, that the
role of TC member needs to be taken more seriously.  Change will not be decided
because our TC knows best, but because its members collectively have first-hand
experience with the problems at hand, have considered a diversity of potential
solutions, and do the hard work of justifying their conclusions.  Change will
happen not because our TC commands it, but because project-level contributors
have trust in our TC members and value their input.  Only by being more engaged
with the wider community can our TC hope to be an effective force for change.

Respectfully,


Maru
__
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] Please stop reviewing code while asking questions

[Dean Troyer]

On Fri, Apr 24, 2015 at 2:00 PM, Julien Danjou  wrote:

> I like that point and I agree with you. The problem, as someone already
> stated, is that these people are rarely on IRC and sometimes just never
> reply on the review. Right, maybe next time I'll chase them down via
> email. Sometimes I wish we were a little more conservative about who
> could do code review, but well.
>

After a bit of due diligence to track down the reviewer, make a note,
ignore that -1 and move on.  To address the fact that the -1 causes the
review to not appear in many people's dashboards, if that feels like an
issue, do a trivial patchset to actually reset the -1 if no other changes
are otherwise forthcoming.

I've been guilty of doing this (forgetting about a -1 on a review) and like
to think that I'd pass whatever bar was set for reviewers.  Limiting the
pool of reviewers really doesn't fix the problem and sets a bad tone for
the project. See all of the discussions about core status and exclusivity,
we don't need to inflict more of that on ourselves.

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] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

[Joe Gordon]

On Fri, Apr 24, 2015 at 12:36 AM, Victor Stinner 
wrote:

> Hi,
>
> I wrote my spec to Port Nova to Python 3:
> https://review.openstack.org/#/c/176868/
>
> >> I squashed all my commits into a single commit of my draft port and I
> pushed it at:
> >>
> https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d
> >
> > I like how the sha1 starts with 'bad'
>
> Ah ah, I didn't notice that. I would prefer "python" prefix, but it's not
> possible.
>
> > Overall that is a pretty small patch.
>
> Cool.
>
> > My general concern, is having to manually review new code for python3
> compliance.
>
> Do you prefer a single very large patch (as the one I posted above) or
> multiple small patches fixing similar issues?


> > If this will take more then a week or two to make a big project python3
> compat (during a virtual sprint), it would be good to have some tooling in
> place to make sure we don't add a lot more burden on reviewers to make sure
> new patches are python3 compatible by hand.
>
> I tried to write a detailed plan in my spec. Until "tox -e py34" pass, I
> would prefer to not touch nova gates nor any add Python 3 checks.
>

Great, I'll follow up on that spec.


>
> Victor
>
> __
> 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] [Nova] Reviewers please watch the check-tempest-dsvm-cells job now

[Matt Riedemann]

On 4/21/2015 2:00 PM, Andrew Laski wrote:

It's been a long road but due to the hard work of bauzas and melwitt the
cells Tempest check job should now be green for changes that don't break
cells.  The job has been red for a long time so it's likely that people
don't think about it much.  I would ask that until we can get the
confidence to make it voting please take notice when it's red and
investigate or bring it to the attention of one of us in #openstack-nova.

__
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



I opened a couple of new bugs today since I had a cells job failure in a 
change that wasn't related to cells (was just adding some debug logging 
somewhere else).


1. https://bugs.launchpad.net/nova/+bug/1448316

That looks like a legit race failure in the cells job only.

2. https://bugs.launchpad.net/nova/+bug/1448302

This is more cosmetic than anything, it doesn't appear to be related to 
anything functionally breaking.  We should get the trace cleaned up 
though since it makes debugging the cells job failures harder.


--

Thanks,

Matt Riedemann


__
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] [nova] Port Nova to Python 3

[Joshua Harlow]

Sean Toner wrote:

On Friday, April 24, 2015 11:20:03 AM Joshua Harlow wrote:

Sean Toner wrote:

If written to use python 3, I hope it will use all the new features
of python 3.4 moving forward.

For example, argument annotations, coroutines, asyncio, etc.  At my
last workplace, we tried to make our project python2 and 3
compatible (ie, you could run it under 2.7 or 3.3+) but this was
the worst of all worlds.

Likely the reality of things is different from the desires :)

I know we'd all love to just do the above (or some of us would like
to), but we also need to think about what shiny new features really
make the quality of nova any better (IMHO some of the above really
don't change much for the better...)

Out of curiosity why was your experience 'the worst of all worlds'?


Like I answered to Victor, it means that you don't get the nice new
features only available in python3 (argument annotations, coroutines,
namespace packaging, etc) while at the same time dealing with the
inconsistencies between python2 and 3 code.


Time to start nova-redux[1] (dubstep remix?), best of luck :)

[1] 
http://www.gossamer-threads.com/lists/openstack/dev/7837?do=post_view_threaded#7837




For example, having to manage some imports, dealing with some functions
now returning bytes instead of str, and all kinds of other fun :)

Here's one example of having to change an import:

try:
 from urllib.request import urlopen
 from urllib.parse import urlparse as urlparse
except ImportError:
 from urllib2 import urlopen
 from urlparse import urlparse

I also had some code that created a subprocess.Popen object to execute
some command.  Some commands output got returned as a regular str, and
some others got returned as bytes.  So I wound up in my class creating a
defensive decorator function that called

if  isinstance(output, bytes):
   return output.decode()

And that's just 2 that popped into my head :)  And it was frustrating
having to do extra work, and yet not be able to partake of all the
python3 goodies.

But, if this is a stepping stone to a pure python3 environment even if
that takes until python2 to EOL, I'm ok with that :)


Regards,
Sean

On Friday, April 24, 2015 04:34:48 AM Victor Stinner wrote:

Hi,

Porting OpenStack applications during the Liberty Cycle was
discussed
last days in the thread "[oslo] eventlet 0.17.3 is now fully Python
3
compatible".

I wrote a spec to port Nova to Python 3:
 https://review.openstack.org/#/c/176868/

I mentioned the 2 other Python 3 specs for Neutron and Heat.

You can reply to this email, or comment the review, if you want to
discuss Python 3 in Nova, or if you have any question related to
Python 3.

See also the Python 3 wiki page:
 https://wiki.openstack.org/wiki/Python3

Thanks,
Victor

___
___  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 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 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] [barbican] Utilizing the KMIP plugin

[Christopher N Solis]

Hello,

I have some questions concerning what exactly is implemented with respect
to the kmip plugin.
When I attempt to store a symmetric key using the command:

curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:12345' -d
'{"name": "AES key", "algorithm":"aes", "bit_length":256,
"mode":"cbc","payload":"9A855DC48159F6629EBFF919C045C24B57B6B0327AA43FAA5DD6C87FC3E000AB","payload_content_type":"application/octet-stream","payload_content_encoding":"base64",
 "secret_type":"symmetric"}'
http://localhost:9311/v1/secrets

I receive the following error: SecretGeneralException: Problem seen during
crypto processing - Reason: 'NoneType' object has no attribute 'enum'

When I also ask barbican to generate a symmetric key using the orders
resource:

curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d
'{ "type":"key", "meta": {"name": "secretname", "algorithm": "aes",
"bit_length": 256, "mode": "cbc", "payload_content_type":
"application/octet-stream"}}' http://localhost:9311/v1/orders

I get what appears to be the same error: AttributeError: 'NoneType' object
has no attribute 'enum'

Does this mean symmetric key storage is still not fully implemented? Or is
it possible there is a misconfiguration between my kmip plugin and
barbican?
Thank you!

Chris Solis




From:   Christopher N Solis/Austin/IBM@IBMUS
To: "Coffman, Joel M." 
Cc: "Reller, Nathan S." , "'OpenStack
Development Mailing List \(not for usage questions\)'"
, "Farr, Kaitlin M."

Date:   04/21/2015 03:50 PM
Subject:Re: [openstack-dev] [barbican] Utilizing the KMIP plugin



Hey Joel.
Thanks for the advice!
I was able to solve the problem and have the ssl connection become trusted.

Barbican seems to be authenticating correctly to the KMIP server as well
now.
However, I have another problem.

When I try to store a plain text secret into barbican I receive the
following error:

File "/home/swift/barbican/barbican/api/controllers/__init__.py", line 104,
in handler
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
90, in enforcer
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/__init__.py", line
146, in content_types_enforcer
return fn(inst, *args, **kwargs)
  File "/home/swift/barbican/barbican/api/controllers/secrets.py", line
326, in on_post
transport_key_id=data.get('transport_key_id'))
  File "/home/swift/barbican/barbican/plugin/resources.py", line 95, in
store_secret
plugin_name=plugin_name)
  File "/home/swift/barbican/barbican/plugin/interface/secret_store.py",
line 478, in _check_plugins_configured
return plugin_related_function(self, *args, **kwargs)
  File "/home/swift/barbican/barbican/plugin/interface/secret_store.py",
line 513, in get_plugin_store
if ext.obj.store_secret_supports(key_spec):
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line
481, in store_secret_supports
return self.generate_supports(key_spec)
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line
437, in generate_supports
alg_dict_entry = self.valid_alg_dict.get(key_spec.alg.lower())
AttributeError: 'NoneType' object has no attribute 'lower'

I don't really know what could be causing this error. Any ideas?

Regards,

  CHRIS SOLIS



Inactive hide details for "Coffman, Joel M." ---04/16/2015 03:22:25
PM---However, I cannot not make a request to the kmip plugi"Coffman, Joel
M." ---04/16/2015 03:22:25 PM---However, I cannot not make a request to the
kmip plugin because of an ssl error: The keyfile, certfi

From: "Coffman, Joel M." 
To: "'OpenStack Development Mailing List (not for usage questions)'"
, Christopher N Solis/Austin/IBM@IBMUS
Cc: "Reller, Nathan S." , "Farr, Kaitlin M."
, "Coffman, Joel M." 
Date: 04/16/2015 03:22 PM
Subject: RE: [openstack-dev] [barbican] Utilizing the KMIP plugin



However, I cannot not make a request to the kmip plugin because of an ssl
error:
The keyfile, certfile, and ca_certs are passed directly to ssl.wrap_socket.
Debugging any SSL errors isn’t easy – Google is generally the best resource
to identify and resolve issues based on the error codes returned by
OpenSSL. :-(

What exactly is each variable suppose to contain?
See the ssl.wrap_socket documentation for more details.
I have keyfile and certfile being a self signed certificate and 2048 bit
RSA key respectively for barbican to use and ca_certs is the kmip_plugins'
certificate for barbican to trust. Does this setup sound right?
In the sentence, you swap the key and certificate (i.e., the RSA key should
be the keyfile and the self-signed certificate should be the certfile), but
that’s probably not the real issue. :-)

If credentials (i.e., a key and certificate) weren’t provided to you for
the KMIP appliance, you’ll probably need to have the KMIP appliance sign
your self-signed certificate so it knows that it’s valid. The procedure
diffe

Re: [openstack-dev] TC Candidacy

[Maru Newby]

> On Apr 24, 2015, at 6:17 AM, Luke Gorrie  wrote:
> 
> Question regarding your candidacy:
> 
> If I recall correctly you have spoken in favor of face to face discussions at 
> mid-cycle meetings as a practical way to set priorities and move things 
> forward. What are your current thoughts on the costs and benefits of this?
> 

I don't think our TC should be involved in a project's decision to hold a
mid-cycle unless legitimate complaints about the openness of the mid-cycle
remain unaddressed by the project's leadership.

My experience is that face-to-face communication can aid in building the
relationships and technical understanding essential to writing good software.
The drawbacks are that proximity can be both expensive and exclusionary.  I
think it's up to each project community to decide whether a mid-cycle is
justified, and if so, work hard to minimize the downsides.  Foundation support
is often available for those that can't afford to attend for financial reasons.
For those that otherwise can't attend, there is the option of encouraging
designation of a representative, ensuring that the mid-cycle is recorded or
logged, and deferring decision-making on explored options to the wider community
after the mid-cycle.


Maru
__
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] Please stop reviewing code while asking questions

[Ryan Brown]

On 04/24/2015 03:00 PM, Julien Danjou wrote:
> I like that point and I agree with you. The problem, as someone already
> stated, is that these people are rarely on IRC and sometimes just never
> reply on the review. Right, maybe next time I'll chase them down via
> email. Sometimes I wish we were a little more conservative about who
> could do code review, but well.

I'm pretty heavily against limiting who can code review. There are some
less-than-helpful reviewers about, but putting up barriers is the wrong
way to go about fixing it.

Education is the way to go, and it's ok if there's some nominal level of
somewhat unhelpful reviews so long as, when possible, we try to teach
those reviewers how they can be more helpful.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
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] [nova] Port Nova to Python 3

[Kevin L. Mitchell]

On Fri, 2015-04-24 at 16:07 -0400, Sean Toner wrote:
> What I meant by the worst of both worlds is that you don't get the nice 
> new features of python3, while simultaneously dealing with the headaches 
> of making code run under both python versions.  You'll have to do weird 
> things with imports (for example urllib) and deal with the 
> inconsistencies between some functions that return strings and some that 
> return unicode, and some that return bytes.
> 
> It's not impossible, but you have to add that extra work while also 
> depriving yourself of the goodness of python3 only features :)

This is why the 'six' library is such a godsend; this stuff is still not
easy, but the hardest parts, like the imports problem, are already taken
care of by six…and maintaining the bytes/strings/unicode distinction is
actually just as useful in Python 2, it just doesn't have the machinery
to really detect the mixing :)
-- 
Kevin L. Mitchell 
Rackspace


__
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] [nova] Port Nova to Python 3

[Sean Toner]

On Friday, April 24, 2015 11:20:03 AM Joshua Harlow wrote:
> Sean Toner wrote:
> > If written to use python 3, I hope it will use all the new features
> > of python 3.4 moving forward.
> > 
> > For example, argument annotations, coroutines, asyncio, etc.  At my
> > last workplace, we tried to make our project python2 and 3
> > compatible (ie, you could run it under 2.7 or 3.3+) but this was
> > the worst of all worlds.
> 
> Likely the reality of things is different from the desires :)
> 
> I know we'd all love to just do the above (or some of us would like
> to), but we also need to think about what shiny new features really
> make the quality of nova any better (IMHO some of the above really
> don't change much for the better...)
> 
> Out of curiosity why was your experience 'the worst of all worlds'?

Like I answered to Victor, it means that you don't get the nice new 
features only available in python3 (argument annotations, coroutines, 
namespace packaging, etc) while at the same time dealing with the 
inconsistencies between python2 and 3 code.

For example, having to manage some imports, dealing with some functions 
now returning bytes instead of str, and all kinds of other fun :)

Here's one example of having to change an import:

try:
from urllib.request import urlopen
from urllib.parse import urlparse as urlparse
except ImportError:
from urllib2 import urlopen
from urlparse import urlparse

I also had some code that created a subprocess.Popen object to execute 
some command.  Some commands output got returned as a regular str, and 
some others got returned as bytes.  So I wound up in my class creating a 
defensive decorator function that called 

if  isinstance(output, bytes):
  return output.decode()

And that's just 2 that popped into my head :)  And it was frustrating 
having to do extra work, and yet not be able to partake of all the 
python3 goodies.

But, if this is a stepping stone to a pure python3 environment even if 
that takes until python2 to EOL, I'm ok with that :)

> 
> > Regards,
> > Sean
> > 
> > On Friday, April 24, 2015 04:34:48 AM Victor Stinner wrote:
> >> Hi,
> >> 
> >> Porting OpenStack applications during the Liberty Cycle was
> >> discussed
> >> last days in the thread "[oslo] eventlet 0.17.3 is now fully Python
> >> 3
> >> compatible".
> >> 
> >> I wrote a spec to port Nova to Python 3:
> >> https://review.openstack.org/#/c/176868/
> >> 
> >> I mentioned the 2 other Python 3 specs for Neutron and Heat.
> >> 
> >> You can reply to this email, or comment the review, if you want to
> >> discuss Python 3 in Nova, or if you have any question related to
> >> Python 3.
> >> 
> >> See also the Python 3 wiki page:
> >> https://wiki.openstack.org/wiki/Python3
> >> 
> >> Thanks,
> >> Victor
> >> 
> >> ___
> >> ___  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 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] [nova] Port Nova to Python 3

[Sean Toner]

On Friday, April 24, 2015 09:13:14 AM Victor Stinner wrote:
> Hi,
> 
> > If written to use python 3, I hope it will use all the new features
> > of python 3.4 moving forward.
> 
> The spec adds Python 3 support, but it keeps Python 2 support. It's
> too early to drop Python 2, Nova is deployed everywhere with Python
> 2.
> > For example, argument annotations, coroutines, asyncio, etc.
> 
> Argument annotations are not used in practice :-( There is a PEP under
> review which targets the future Python 3.5 version:
> 
>https://www.python.org/dev/peps/pep-0484/
> 

Yeah, that is a shame.  I know many who are vehemently against argument 
annotations or type hinting, but i think it has its usefulness.

> I'm working actively on asyncio. I wrote a spec to replace eventlet
> with asyncio:
> 
>https://review.openstack.org/#/c/153298/
>superseded by: https://review.openstack.org/#/c/164035/
> 
> For OpenStack, I ported asyncio to Python 2: it's the Trollius
> project:
> 
>https://trollius.readthedocs.org/
> 
> I would also prefer to be able to use new shiny Python 3 features, but
> it's not possible yet. We have to move step by step. There is no
> choice like "Python 2 only" or "Python 3 only with new Python 3
> features". Changes must be done incrementally in OpenStack. We all
> know that.

I understand.  I hope this is a stepping stone to python 3 only :)

> > At my last workplace, we tried to make our project python2 and 3
> > compatible (ie, you could run it under 2.7 or 3.3+) but this was
> > the worst of all worlds.
> 
> Does it mean that you are against the whole spec?
> 
> I don't know any Python project in the wild which was really ported to
> Python 3: drop Python 2 support at the same time. Supporting only
> Python 3 only slowly becomes a good choice for *new* projects.
> 

This was a proprietary project at another company, so it wasn't open 
source. 

I'm not against the spec as it is.  If nothing else, it paves the way to 
eventually use the nice python 3+ only features :)

What I meant by the worst of both worlds is that you don't get the nice 
new features of python3, while simultaneously dealing with the headaches 
of making code run under both python versions.  You'll have to do weird 
things with imports (for example urllib) and deal with the 
inconsistencies between some functions that return strings and some that 
return unicode, and some that return bytes.

It's not impossible, but you have to add that extra work while also 
depriving yourself of the goodness of python3 only features :)

> All projects are ported by adding Python 3 support in addition to
> Python 2 support. The six module is a great module to limit changes
> on the source code.
> 
> See my early draft patch to port nova to Python 3:
> 
>   
> https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70
> 138bd89d
> 
> Joe Goron wrote "I like how the sha1 starts with 'bad'. Overall that
> is a pretty small patch." ;-)
> 
> Victor
> 
> __
>  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] [oslo] Deprecation path?

[Doug Hellmann]

Excerpts from Julien Danjou's message of 2015-04-24 21:06:47 +0200:
> Hi Oslo team!
> 
> So what's your deprecation path?
> 
> I sent a patch for oslo.utils¹ using debtcollector, our new fancy
> deprecation tool, and I got a -2 stating that there's no way we
> deprecate something being used, and that we need to remove usage from
> the projects first.

The issue with simply using debtcollector to signal the deprecation is
that it emits warnings in logs, which most of the developers don't see
until we have too many warnings and the logs cause issues with the gate.

We're past the point where we can assume most OpenStack developers
are aware of Oslo changes, or plans, or intent. We need to be doing
more advertising of major work, including deprecations.  I don't
expect you to do all of the advertising or updates to other projects
yourself, that's why we have liaisons in the first place.

This mailing list thread is a good start on announcing a deprecation,
and I would like to see a couple of liaisons sign up to help with
updates before we go ahead with the implementation.

Doug

> 
> I don't necessarily agree with this, but I accepted the challenge
> anyway. I started by writing only patches for Nova² and Cinder³, and now I
> see people complaining that my patch can't be merged because the
> function is not deprecated in Oslo.
> 
> So before I start flipping tables, what do we do?
> 
> 
> ¹  https://review.openstack.org/#/c/148500/
> 
> ²  https://review.openstack.org/#/c/164753/
> 
> ³  https://review.openstack.org/#/c/165798/
> 

__
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] [oslo] Deprecation path?

[Doug Hellmann]

Excerpts from Robert Collins's message of 2015-04-25 07:21:18 +1200:
> I think it needs a three-step dance.
> 
> 1) Commit the intent to deprecate but don't signal it programmatically.

I'm not sure what this means. A spec? A bug? A comment?

> 2) Work with known direct users to remove usage.
> 3) Programmatically signal deprecation and maintain until a major
> release is made.
> 
> -Rob
> 
> On 25 April 2015 at 07:06, Julien Danjou  wrote:
> > Hi Oslo team!
> >
> > So what's your deprecation path?
> >
> > I sent a patch for oslo.utils¹ using debtcollector, our new fancy
> > deprecation tool, and I got a -2 stating that there's no way we
> > deprecate something being used, and that we need to remove usage from
> > the projects first.
> >
> > I don't necessarily agree with this, but I accepted the challenge
> > anyway. I started by writing only patches for Nova² and Cinder³, and now I
> > see people complaining that my patch can't be merged because the
> > function is not deprecated in Oslo.
> >
> > So before I start flipping tables, what do we do?
> >
> >
> > ¹  https://review.openstack.org/#/c/148500/
> >
> > ²  https://review.openstack.org/#/c/164753/
> >
> > ³  https://review.openstack.org/#/c/165798/
> >
> > --
> > 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
> >
> 

__
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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

[Marcus Vinícius Ramires do Nascimento]

Hi Ramy,

Take me in account. I'm interested in a common solution and I'm trying to
get more involved in the community, so I think that could be a nice
initiative to contribute to the community. If I can help, would be awesome.
I'll start to attend to third party ci meetings.


Regards

On Fri, Apr 24, 2015 at 3:45 PM, Sukhdev Kapur 
wrote:

> Hi Anita,
>
> Thanks for the clarification. I will plan on attending the summit session
> on this topic (proposed by Kurt, I believe).
> I have to admit that I have to always keep an eye out to ensure nothing is
> broken in our CI because of any upgrade of packages, etc. and act
> accordingly. If new unified framework can reduce/eliminate this effort, I
> would like to at least understand it and discuss with the participants -
> and, may join in.
>
> Thanks for the good work.
> -Sukhdev
>
>
>
> On Tue, Apr 21, 2015 at 11:25 AM, Anita Kuno  wrote:
>
>> On 04/20/2015 04:39 PM, Sukhdev Kapur wrote:
>> > Hi Ramy,
>> >
>> > While I agree, in principal, with this line of thinking and goal, my
>> > concern will be how much extra work is it going to create for existing
>> CI
>> > owners?
>> > Our Ci system has been stable for a long time, and we put in a good
>> amount
>> > of effort to get it to that point. Our CI is not based upon zuul
>> framework.
>> > Zuul was still under discussion at the time when we put together our
>> CI. We
>> > use Jenkins as front end, along with Gerrit triggers, and AWS for
>> > posting/preserving results/log.  We have dedicated back-end servers for
>> >  testing.
>> >
>> > My paranoia at this point will be to learn a new framework, risk
>> breaking
>> > things and taking a huge effort to get things stabilized - without much
>> > additional ROI.
>> > Am I overreacting here or does my argument makes sense?
>> >
>> > I wonder how many folks will be in that camp?
>> >
>> > Sukhdev
>> Hi Sukhdev:
>>
>> What is being offered is an opportunity to pool efforts for those who
>> wish to participate. There is no pressure to participate if you are
>> concerned that you would compromise the integrity of a stable system.
>> You and others that have put in so much work are to be lauded for your
>> commitment to your goal, thank you. Ramy's efforts in no way are an
>> attempt to degrade the stability you have created.
>>
>> Part of the exhaustion level folks feel in this space, at all points in
>> the spectrum, is the cost of maintenance. In infra we are constantly
>> dealing with problems from operators and it would reduce the burden on
>> us, as well as reduce the tension on operators, if we had a solution
>> that was easier to maintain. The more people running the same structure,
>> the easier any one issue is to solve (hopefully).
>>
>> The goal is once the structure is in place that OpenStack's Infra would
>> also consume it, enabling common bugs to be discovered and fixed upstream.
>>
>> Noone is forced to participate nor are they going to be forced to
>> operate this structure. This is simply a chance to work together on a
>> direction which infra would very much like to see in place.
>>
>> Thanks Sukhdev,
>> Anita.
>> >
>> >
>> >
>> >
>> > On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy 
>> wrote:
>> >
>> >>  All Third-Party CI operators:
>> >>
>> >>
>> >>
>> >> We’ve got 85 Third Party CI systems registered in the wiki[1], all of
>> them
>> >> running a variety of closed & open-source solutions.
>> >>
>> >> Instead of individually maintaining all those similar solutions, let’s
>> >> join together and collectively maintain a single solution.
>> >>
>> >>
>> >>
>> >> If that sounds good to you, there’s an Infra-spec that’s been approved
>> [2]
>> >> to refactor much of what the Infrastructure team uses for the upstream
>> >> “Jenkins” CI to be more easily reusable by many of us.
>> >>
>> >>
>> >>
>> >> We’ve got stories defined [3], and a few patches submitted. We’re using
>> >> the gerrit-topic “downstream-puppet” [4].
>> >>
>> >>
>> >>
>> >> For example, we’ve got the first part under review for the “Log
>> Server”,
>> >> which creates your own version of http://logs.openstack.org/
>> >>
>> >>
>> >>
>> >> If anyone is interested in migrating towards a common solution, reply,
>> or
>> >> ping me IRC (asselin) on Freenode #openstack-infra, or join some of the
>> >> third party ci meetings [5].
>> >>
>> >>
>> >>
>> >> Thanks!
>> >>
>> >> Ramy
>> >>
>> >>
>> >>
>> >> [1] https://wiki.openstack.org/wiki/ThirdPartySystems
>> >>
>> >> [2]
>> >>
>> http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
>> >>
>> >> [3] https://storyboard.openstack.org/#!/story/2000101
>> >>
>> >> [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z
>> >>
>> >> [5]
>> >>
>> https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscr

Re: [openstack-dev] [oslo] Deprecation path?

[Brant Knudson]

On Fri, Apr 24, 2015 at 2:21 PM, Robert Collins 
wrote:

> I think it needs a three-step dance.
>
> 1) Commit the intent to deprecate but don't signal it programmatically.
>

Python's warnings package has a PendingDeprecationWarning for this --
https://docs.python.org/2.6/library/warnings.html#warning-categories

- Brant
__
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] [oslo] Deprecation path?

[Robert Collins]

I think it needs a three-step dance.

1) Commit the intent to deprecate but don't signal it programmatically.
2) Work with known direct users to remove usage.
3) Programmatically signal deprecation and maintain until a major
release is made.

-Rob

On 25 April 2015 at 07:06, Julien Danjou  wrote:
> Hi Oslo team!
>
> So what's your deprecation path?
>
> I sent a patch for oslo.utils¹ using debtcollector, our new fancy
> deprecation tool, and I got a -2 stating that there's no way we
> deprecate something being used, and that we need to remove usage from
> the projects first.
>
> I don't necessarily agree with this, but I accepted the challenge
> anyway. I started by writing only patches for Nova² and Cinder³, and now I
> see people complaining that my patch can't be merged because the
> function is not deprecated in Oslo.
>
> So before I start flipping tables, what do we do?
>
>
> ¹  https://review.openstack.org/#/c/148500/
>
> ²  https://review.openstack.org/#/c/164753/
>
> ³  https://review.openstack.org/#/c/165798/
>
> --
> 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
>



-- 
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] [metrics] what answers do you expect from counting comments? (was Re: Please stop reviewing code while asking questions)

[Amrith Kumar]

But I thought we set out to solve the problem of questions with -1's. That 
problem would be solved ;)

-amrith

| -Original Message-
| From: Ed Leafe [mailto:e...@leafe.com]
| Sent: Friday, April 24, 2015 1:13 PM
| To: openstack-dev@lists.openstack.org
| Subject: Re: [openstack-dev] [metrics] what answers do you expect from
| counting comments? (was Re: Please stop reviewing code while asking
| questions)
| 
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA512
| 
| On 04/24/2015 11:50 AM, Amrith Kumar wrote:
| 
| > I'm not interested in these numbers, personally (well, other than the
| > usual fishing stories at summit after umpteen beers; I did 14
| > bazillion reviews in Kilo, how many did you do?).
| >
| > My concern (earlier in the thread) is that there is a metric. Once
| > there's a metric someone attempts to use it to measure performance.
| > And once someone uses a metric to measure performance, it influences
| > behavior.
| >
| > If I propose that a +0 should now get counted, given how overloaded
| > the CI is, I don't want the system to get abused by wanton 'recheck's
| > which start to count towards performance.
| 
| Be careful what you wish for; you just might get it... :)
| 
| If people are going to game the system, changing a rule here or there
| won't stop them. Now if +0 are counted, what's to stop someone from adding
| +0s to every review? It won't affect the flow, and damn, they'll get to 14
| bazillion reviews without breaking a sweat!
| 
| - --
| 
| - -- Ed Leafe
| -BEGIN PGP SIGNATURE-
| Version: GnuPG v2
| Comment: GPGTools - https://gpgtools.org
| Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
| 
| iQIcBAEBCgAGBQJVOnmUAAoJEKMgtcocwZqLpyMP/26agq1OyGLwFjQdp2tJN+yV
| 1nX5m5Rv/OrraFlxIUOBapbiwnT0nwoOXEiHLW/7ofIJIML7uthFi5bSt0Hynmeq
| 8rfRf+EEGuW0q7h4jgsBCsMD9idrn+ohsYVfqht6+P2co4kglz+VKX56EcRrm/Gx
| tQO8dYZhe4ztBDe27KVwxKIAnbHSEqWCEH1PouP1/QFy0402SVtSaFfBh4FI7W8G
| snHDV2aJywmNIHOoNJBanwWRLPQkxR2Z3chMVoHKMGu4T2PX8HLOeuyeSM5luEZL
| ojpJad7ZZFwRlpYDZt+9hJ76rhur0btg6wbHzI6cIfMXVURWv9EXnWlqbFvTv8wc
| BP7pwbbIV9MfGrlYdRSbVeXSRTXoHCLl/mUWShdx9XSbFu8Cf0E6vFjHDqA+mcF4
| n0zq2SPdoQ2/C1pWRSfHj7xPjRaGIUK4gCBKdOCkKpjGSYQG77QnVShQ0ZrzN/EG
| SQYyyETVNohrgEdPdoY9wUPIXyd5Jvd5vLZ0iceGDRPdI9EmO/TJjR8oElwscYpc
| PKIw0c9bgKEWbVaqMNltcCFixlxUDZqSjMxskS4/Yvbd3k/i89z0ezbiI1HGawmd
| +pRKD7stG4ea5a1InRaKh8Qz3qPt4Itq6yxUE2DA7F7Jav3Cfa/nGxhlWL22FzTO
| LCCUva3cpOMMqgMTN09I
| =0NDE
| -END PGP SIGNATURE-
| 
| __
| 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] [oslo] Deprecation path?

[Julien Danjou]

Hi Oslo team!

So what's your deprecation path?

I sent a patch for oslo.utils¹ using debtcollector, our new fancy
deprecation tool, and I got a -2 stating that there's no way we
deprecate something being used, and that we need to remove usage from
the projects first.

I don't necessarily agree with this, but I accepted the challenge
anyway. I started by writing only patches for Nova² and Cinder³, and now I
see people complaining that my patch can't be merged because the
function is not deprecated in Oslo.

So before I start flipping tables, what do we do?


¹  https://review.openstack.org/#/c/148500/

²  https://review.openstack.org/#/c/164753/

³  https://review.openstack.org/#/c/165798/

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


signature.asc
Description: PGP signature
__
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] Please stop reviewing code while asking questions

[Julien Danjou]

On Fri, Apr 24 2015, Joe Gordon wrote:

Hi Joe,

> By calling them out in the review or on irc, and explain to them when its
> appropriate to use a -1.   I don't think its safe to assume that a
> significant number of people who do these -1s are read every thread on the
> ML.

I like that point and I agree with you. The problem, as someone already
stated, is that these people are rarely on IRC and sometimes just never
reply on the review. Right, maybe next time I'll chase them down via
email. Sometimes I wish we were a little more conservative about who
could do code review, but well.

Because that's a lot of time and energy I could also spend improving
OpenStack, so please, let me hope that some of them read that thread.
;-)

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


signature.asc
Description: PGP signature
__
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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

[Sukhdev Kapur]

Hi Anita,

Thanks for the clarification. I will plan on attending the summit session
on this topic (proposed by Kurt, I believe).
I have to admit that I have to always keep an eye out to ensure nothing is
broken in our CI because of any upgrade of packages, etc. and act
accordingly. If new unified framework can reduce/eliminate this effort, I
would like to at least understand it and discuss with the participants -
and, may join in.

Thanks for the good work.
-Sukhdev



On Tue, Apr 21, 2015 at 11:25 AM, Anita Kuno  wrote:

> On 04/20/2015 04:39 PM, Sukhdev Kapur wrote:
> > Hi Ramy,
> >
> > While I agree, in principal, with this line of thinking and goal, my
> > concern will be how much extra work is it going to create for existing CI
> > owners?
> > Our Ci system has been stable for a long time, and we put in a good
> amount
> > of effort to get it to that point. Our CI is not based upon zuul
> framework.
> > Zuul was still under discussion at the time when we put together our CI.
> We
> > use Jenkins as front end, along with Gerrit triggers, and AWS for
> > posting/preserving results/log.  We have dedicated back-end servers for
> >  testing.
> >
> > My paranoia at this point will be to learn a new framework, risk breaking
> > things and taking a huge effort to get things stabilized - without much
> > additional ROI.
> > Am I overreacting here or does my argument makes sense?
> >
> > I wonder how many folks will be in that camp?
> >
> > Sukhdev
> Hi Sukhdev:
>
> What is being offered is an opportunity to pool efforts for those who
> wish to participate. There is no pressure to participate if you are
> concerned that you would compromise the integrity of a stable system.
> You and others that have put in so much work are to be lauded for your
> commitment to your goal, thank you. Ramy's efforts in no way are an
> attempt to degrade the stability you have created.
>
> Part of the exhaustion level folks feel in this space, at all points in
> the spectrum, is the cost of maintenance. In infra we are constantly
> dealing with problems from operators and it would reduce the burden on
> us, as well as reduce the tension on operators, if we had a solution
> that was easier to maintain. The more people running the same structure,
> the easier any one issue is to solve (hopefully).
>
> The goal is once the structure is in place that OpenStack's Infra would
> also consume it, enabling common bugs to be discovered and fixed upstream.
>
> Noone is forced to participate nor are they going to be forced to
> operate this structure. This is simply a chance to work together on a
> direction which infra would very much like to see in place.
>
> Thanks Sukhdev,
> Anita.
> >
> >
> >
> >
> > On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy 
> wrote:
> >
> >>  All Third-Party CI operators:
> >>
> >>
> >>
> >> We’ve got 85 Third Party CI systems registered in the wiki[1], all of
> them
> >> running a variety of closed & open-source solutions.
> >>
> >> Instead of individually maintaining all those similar solutions, let’s
> >> join together and collectively maintain a single solution.
> >>
> >>
> >>
> >> If that sounds good to you, there’s an Infra-spec that’s been approved
> [2]
> >> to refactor much of what the Infrastructure team uses for the upstream
> >> “Jenkins” CI to be more easily reusable by many of us.
> >>
> >>
> >>
> >> We’ve got stories defined [3], and a few patches submitted. We’re using
> >> the gerrit-topic “downstream-puppet” [4].
> >>
> >>
> >>
> >> For example, we’ve got the first part under review for the “Log Server”,
> >> which creates your own version of http://logs.openstack.org/
> >>
> >>
> >>
> >> If anyone is interested in migrating towards a common solution, reply,
> or
> >> ping me IRC (asselin) on Freenode #openstack-infra, or join some of the
> >> third party ci meetings [5].
> >>
> >>
> >>
> >> Thanks!
> >>
> >> Ramy
> >>
> >>
> >>
> >> [1] https://wiki.openstack.org/wiki/ThirdPartySystems
> >>
> >> [2]
> >>
> http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
> >>
> >> [3] https://storyboard.openstack.org/#!/story/2000101
> >>
> >> [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z
> >>
> >> [5]
> >>
> https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
> >>
> >>
> >>
> >>
> >>
> >>
> __
> >> 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Brant Knudson]

On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German <
german.eichber...@hp.com> wrote:

> All,
>
> Following up from the last Neutron meeting:
>
> If Neutron is performing an operation as an admin on behalf of a user that
> user's tenant-id (or project-id) isn't validated - in particular an admin
> can mistype and create object on behalf of non existent users. I am
> wondering how other projects (e.g. Nova) deal with that and if there is
> some API support in keystone to save us a round trip (e.g. authenticate
> admin + validate additional user-id).
>
>
Not to long ago we got support in the auth_token middleware for a "service"
token in addition to the user's token. The user token is sent in the
x-auth-token header and the service token is sent in the x-service-token,
and then fields from both tokens are available to the application (e.g.,
the user project is in HTTP_X_PROJECT_ID and the service token roles are in
HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the
server for the operation that required the service token to have the
'service' role, and what neutron could do is send the original user token
in x-auth-token and send its own token as the service token. This seems to
be what you're asking for here.

- Brant



> Thanks,
> German
>
> __
> 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] Please stop reviewing code while asking questions

[Jeremy Stanley]

On 2015-04-24 11:01:53 -0700 (-0700), Joe Gordon wrote:
[...]
> in trying to figure out why that line is there I do a git blame
> only to see a useless commit message with me as the author.
[...]

"Always wanted to travel back in time to try fighting a younger
version of yourself? Software development is the career for you!"
[attributed to Elliot Loh]

__
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] Question for the TC candidates

[Zane Bitter]

On 24/04/15 09:52, Ed Leafe wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/24/2015 08:30 AM, Zane Bitter wrote:


I'm not sure what you see as the difference between the "end
users" and the "operators" of OpenStack, because in my mind they
are one and the same. I don't consider the people using, say,
public cloud services to be OpenStack end users, because
ultimately they just want stuff that works, and if it doesn't,
they'll blame the provider, not OpenStack. I see our end users as
the people who deploy and run OpenStack clouds.


Whoa! Back the terminology train up.

There's been longstanding confusion whenever anyone mentions the
word "users" because it is ambiguous whether it refers to the
people who deploy OpenStack clouds or the people who deploy
workloads on them. This has largely been resolved by a conscious
effort to refer to the two groups as "operators" and "end users"
respectively.

The *last* thing we need is to muddy the waters again since,
contrary to your (I hope inadvertent) implication, both groups are
important and they often have different (and occasionally
conflicting) interests. The qualifier "end" is there for a reason;
don't ignore it.


Well, of course they are important, and shouldn't be ignored, but the
question explicitly stated:


I'm concerned with are the developers, end-users and operators of
OpenStack: the individuals who are actively involved with it on a
daily basis. I'm intentionally leaving out things like "the
downstream".


I read "the downstream" to mean what you refer to as "people who
deploy workloads on them".


"Downstream" means people who package/distribute OpenStack. To those of 
us (like Chris) who also do this as well as being developers it's 
literally an everyday term, but this was a good reminder to me that not 
everyone shares the same context :)



 In this context, I saw the operators as the
end-users of the work the devs do. If that gave the impression that I
don't care about people who actually run their stuff on the clouds we
build, I apologize - I was simply trying to answer what was asked.


Thanks for clarifying, I understand your meaning much better now.

cheers,
Zane.

__
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] Please stop reviewing code while asking questions

[Joe Gordon]

On Fri, Apr 24, 2015 at 11:16 AM, Julien Danjou  wrote:

> On Fri, Apr 24 2015, Joe Gordon wrote:
>
> > When I get a -1 on one of my patches with a question, I personally treat
> it
> > as a short coming of the commit message. To often in the past I have
> looked
> > at a file, and in trying to figure out why that line is there I do a git
> > blame only to see a useless commit message with me as the author.
>
> That's a thing that I've been stated over and over again in this thread
> and actually paraphrased from the first paragraph on my original email.
> It'd be cool if we could stop restating the obvious over and over again.
>


So you did, sorry.



>
>
> Could someone give me an example of how we are supposed to improve the
> patch or commit message when one get a -1 with e.g. the question:
>   "Why do you use getattr(foo, "bar", None)?"
>
>
By calling them out in the review or on irc, and explain to them when its
appropriate to use a -1.   I don't think its safe to assume that a
significant number of people who do these -1s are read every thread on the
ML.



> when the answer is "Well, otherwise it will raise an error and the code
> will fail" because the reviewer do not know how getattr() works.
>
> --
> 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

Re: [openstack-dev] [nova] Port Nova to Python 3

[Joshua Harlow]

Sean Toner wrote:

If written to use python 3, I hope it will use all the new features of
python 3.4 moving forward.

For example, argument annotations, coroutines, asyncio, etc.  At my last
workplace, we tried to make our project python2 and 3 compatible (ie,
you could run it under 2.7 or 3.3+) but this was the worst of all
worlds.


Likely the reality of things is different from the desires :)

I know we'd all love to just do the above (or some of us would like to), 
but we also need to think about what shiny new features really make the 
quality of nova any better (IMHO some of the above really don't change 
much for the better...)


Out of curiosity why was your experience 'the worst of all worlds'?



Regards,
Sean

On Friday, April 24, 2015 04:34:48 AM Victor Stinner wrote:

Hi,

Porting OpenStack applications during the Liberty Cycle was discussed
last days in the thread "[oslo] eventlet 0.17.3 is now fully Python 3
compatible".

I wrote a spec to port Nova to Python 3:

https://review.openstack.org/#/c/176868/

I mentioned the 2 other Python 3 specs for Neutron and Heat.

You can reply to this email, or comment the review, if you want to
discuss Python 3 in Nova, or if you have any question related to
Python 3.

See also the Python 3 wiki page:

https://wiki.openstack.org/wiki/Python3

Thanks,
Victor

__
 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 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] [TaskFlow] trying to understand taskflow persistence backend

[Joshua Harlow]

Here's some hopefully useful links:

- http://docs.openstack.org/developer/taskflow/persistence.html
- 
http://docs.openstack.org/developer/taskflow/persistence.html#module-taskflow.storage

- http://docs.openstack.org/developer/taskflow/#examples

From other folks:

- https://github.com/sputnik13/taskflow_tutorial
- http://www.dankrause.net/2014/08/23/intro-to-taskflow.html

Hopefully some/all of the above are useful.

If not please complain/or jump on IRC[1] and yell ;-)

[1] irc://chat.freenode.net/openstack-state-management

Doug Hellmann wrote:

Excerpts from Sumit Jamgade's message of 2015-04-24 13:17:41 +:

Hi,
Is there some place where I can read up how taskflow uses database for 
persistance.Some kind of highlevel flow.

I am trying to read up the code, but some guidelines at arch level will be 
helpfull.
Thanks.--sj


The documentation for taskflow is at
http://docs.openstack.org/developer/taskflow/

I don't know if what you're looking for is there, but taskflow is one of
our better documented libraries, so if it's not there it may not have
been written down yet. :-)

Doug


__
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] Please stop reviewing code while asking questions

[Julien Danjou]

On Fri, Apr 24 2015, Joe Gordon wrote:

> When I get a -1 on one of my patches with a question, I personally treat it
> as a short coming of the commit message. To often in the past I have looked
> at a file, and in trying to figure out why that line is there I do a git
> blame only to see a useless commit message with me as the author.

That's a thing that I've been stated over and over again in this thread
and actually paraphrased from the first paragraph on my original email.
It'd be cool if we could stop restating the obvious over and over again.


Could someone give me an example of how we are supposed to improve the
patch or commit message when one get a -1 with e.g. the question:
  "Why do you use getattr(foo, "bar", None)?"

when the answer is "Well, otherwise it will raise an error and the code
will fail" because the reviewer do not know how getattr() works.

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


signature.asc
Description: PGP signature
__
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] Please stop reviewing code while asking questions

[Joe Gordon]

On Fri, Apr 24, 2015 at 10:31 AM, Doug Hellmann 
wrote:

> Excerpts from Amrith Kumar's message of 2015-04-24 15:02:01 +:
> > There have been many replies on this thread, I'll just reply to this one
> rather than trying to reply piecemeal.
> >
> > Doug, there's asking a question because something is unclear (implying
> that the code is needlessly complex, missing a comment, is unintuitive,
> ...). I believe that this most definitely warrants a -1 as you describe
> because it is indicative that the code, once submitted, would be hard for a
> future reader to follow.
> >
> > In my mind, the yardstick has been, and continues to be this; would a
> reasonable person believe that the patch set as presented should be allowed
> to merge.
> >
> > - If I can answer that question unambiguously, and unequivocally with a
> NO, then I will score the patch with a negative score.
> >
> > - If I can answer that question unambiguously, and unequivocally with a
> YES, then I will score the patch with a positive score.
> >
> > - For anything else, I'll use a 0.
>
> I've run into too many cases where a "trivial" change has an
> unintended consequence, so I suppose I'm more conservative with my
> code reviews. I don't use 0 very often at all, not because of any
> stats counting, but because I don't assume that conveys any information
> to the author or other reviewers. I vote the way I mean for my
> comments to be taken, so I use -1 to indicate that more work is
> needed, even if that work is just explaining something better or
> demonstrating that an edge case is going to be handled.
>
>
When I get a -1 on one of my patches with a question, I personally treat it
as a short coming of the commit message. To often in the past I have looked
at a file, and in trying to figure out why that line is there I do a git
blame only to see a useless commit message with me as the author.


> >
> > If there was a patch to make reviewstats count +0, I'd support that. But
> I would also like to understand what the differences are between
> reviewstats and stackalytics. Ideally I would like stackalytics to count
> 0's as well. If you can take the time to review a patch, you should get
> credit for it (no matter what tool is used to count).
> >
> > I would support changes to both reviewstats and stackalytics to do the
> following.
>
> I'm not sure where all of the interest in stats counting comes from, but
> it's definitely not a motivation of my own behavior.
>
> Doug
>
> __
> 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] [neutron][QoS] service-plugin or not discussion

[Armando M.]

On 24 April 2015 at 01:47, Miguel Angel Ajo Pelayo 
wrote:

> Hi Armando & Salvatore,
>
> On 23/4/2015, at 9:30, Salvatore Orlando  wrote:
>
>
>
> On 23 April 2015 at 01:30, Armando M.  wrote:
>
>>
>> On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo 
>>  wrote:
>>
>>>
>>> Hi everybody,
>>>
>>>In the latest QoS meeting, one of the topics was a discussion about
>>> how to implement
>>> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>>>
>>
> It is really promising that after only two meetings the team is already
> split! I cannot wait for the API discussion to start ;)
>
>
> We seem to be relatively on the same page about how to model the API, but
> we need yet to loop
> in users/operators who have an interest in QoS to make sure they find it
> usable. [1]
>
>
>
>>
>> My apologies if I was unable to join, the meeting clashed with another
>> one I was supposed to attend.
>>
>
> My bad, sorry ;-/
>
>
>>
>>>
>>>It’s my feeling, and Mathieu’s that it looks more like a core
>>> feature, as we’re talking of
>>> port properties that we define at high level, and most plugins (QoS
>>> capable) may want
>>> to implement at dataplane/controlplane level, and also that it’s
>>> something requiring a good
>>> amount of review.
>>>
>>
> "Core" is a term which is recently being abused in Neutron... However, I
> think you mean that it is a feature fairly entangled with the L2 mechanisms,
>
>
> Not only the L2 mechanisms, but the description of ports themselves, in
> the basic cases we’re just defining
> how “small” or “big” your port is.  In the future we could be saying “UDP
> ports 5000-6000” have the highest
> priority on this port, or a minimum bandwidth of 50Mbps…, it’s marked with
> a IPv6 flow label for hi-prio…
> or whatever policy we support.
>
> that deserves being integrated in what is today the "core" plugin and in
> the OVS/LB agents. To this aim I think it's good to make a distinction
> between the management plane and the control plane implementation.
>
> At the management plane you have a few choices:
> - yet another mixin, so that any plugin can add it and quickly support the
> API extension at the mgmt layer. I believe we're fairly certain everybody
> understands mixins are not sustainable anymore and I'm hopeful you are not
> considering this route.
>
>
> Are you specifically referring to this on every plugin?
>
> class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2, <---
> dvr_mac_db.DVRDbMixin, <---
> external_net_db.External_net_db_mixin, <---
> sg_db_rpc.SecurityGroupServerRpcMixin,   <---
> agentschedulers_db.DhcpAgentSchedulerDbMixin,  <---
> addr_pair_db.AllowedAddressPairsMixin,  <
>
> I’m quite allergic to mixings, I must admit, but, if it’s not the desired
> way, why don’t we refactor the way we compose plugins !? (yet more
> refactors probably would slow us down, …) but… I feel like we’re pushing to
> overcomplicate the design for a case which is similar to everything else we
> had before (security groups, port security, allowed address pairs).
>
> It feels wrong to have every similar feature done in a different way, even
> if the current way is not the best one I admit.
>
>
This attitude led us to the pain we are in now, I think we can no longer
afford to keep doing that. Bold goals require bold actions. If we don't
step back and figure out a way to extend the existing components without
hijacking the current codebase, it would be very difficult to give this
effort the priority it deserves.

> - a service plugin - as suggested by some proposers. The service plugin is
> fairly easy to implement, and now Armando has provided you with a mechanism
> to register for callbacks for events in other plugins. This should make the
> implementation fairly straightforward. This also enables other plugins to
> implement QoS support.
> - a ML2 mechanism driver + a ML2 extension driver. From an architectural
> perspective this would be the preferred solution for a ML2 implementation,
> but at the same time will not provide management level support for non-ML2
> plugins.
>
>
> I’m a bit lost of why a a plugin (apart from ML2) could not just declare
> that it’s implementing the extension,  or it’s just that the only way we
> have to do it right now it’s mixings? why would ML2 avoid it?.
>
>
>
>
>>
>>>
>>>In the other hand Irena and Sean were more concerned about having a
>>> good separation
>>> of concerns (I agree actually with that part), and being able to do
>>> quicker iterations on a
>>> separate stackforge repo.
>>>
>>
>> Perhaps we're trying to address the issue at the wrong time. Once a
>> reasonable agreement has been reached on the data model, and the API,
>> whether we're going with a service plugin or core etc should be an
>> implementation detail. I think the crux of the matter is the data plane
>> integration. From a management and control standpoint it should be fairly
>> trivial to

Re: [openstack-dev] Please stop reviewing code while asking questions

[Ben Nemec]

On 04/24/2015 07:11 AM, Russell Bryant wrote:
> On 04/24/2015 07:21 AM, Amrith Kumar wrote:
>> We had a hypothesis about why +0 was rarely used (never conclusively
>> proved). Our hypothesis was that since Stackalytics didn't count +0's
>> it led to an increased propensity to -1 something. It would be
>> wonderful if we could try the experiment of giving credit for 0's and
>> seeing if it changes behavior.
> 
> I think this makes a lot of sense.  These stats really do drive
> behavior.  I'd certainly be open to a patch to reviewstats [1] to count
> +0 comments and I think it would be good for stackalytics to consider
> the same.
> 
> [1] http://git.openstack.org/cgit/openstack-infra/reviewstats
> 

I actually looked at doing this a while ago, but unfortunately the json
data we were getting from Gerrit didn't include no scores.  That may
have been pre-Gerrit upgrade so it's possible it will have changed, but
it's worth noting that we may just not have the ability to track this.

-Ben

__
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] Please stop reviewing code while asking questions

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2015-04-24 15:15:18 +:
> On 2015-04-24 10:23:35 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > I will often ask questions like, "what is going to happen in X
> > situation if we change this default" or "how does this change in
> > behavior affect the case where Y happens, which isn't well tested
> > in our unit tests." If those details aren't made clear by the commit
> > message and comments in the code, I consider that a good reason to
> > include a -1 with a request for the author to provide more detail.
> > Often these are cases I'm not intimately familiar with, so I ask a
> > question rather than saying outright that I think something is
> > broken because I expect to learn from the answer but I still have
> > doubts that I want to indicate with the -1.
> [...]
> 
> Thinking about this though, for the benefit of non-fluent readers
> and cultures where rhetorical questions are a less common construct,
> it's probably better if we make a conscious effort to actually say
> what we mean and give directly actionable feedback when reviewing.
> 
> "Please add code comments here explaining the behavior in the case
> where Y happens, since it isn't well tested in our unit tests." (Or
> even better, "please add tests!")
> 
> A lot of the good "questions" I see in reviews where there's a -1
> (and I'm frequently guilty of this too) could be much more
> effectively phrased as requests to improve code comments, use
> clearer syntax, add more detail in commit messages, or even better
> test the code being added/changed.

That's a fair point. I tend to think of the questions as a way to start
the discussion about the patch, rather than a subtle hint at what I
think might be wrong. If that conversation reaches a point where more
work is obviously needed, then I go ahead and make that request more
plainly.

Doug

__
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] Please stop reviewing code while asking questions

[Doug Hellmann]

Excerpts from Amrith Kumar's message of 2015-04-24 15:02:01 +:
> There have been many replies on this thread, I'll just reply to this one 
> rather than trying to reply piecemeal.
> 
> Doug, there's asking a question because something is unclear (implying that 
> the code is needlessly complex, missing a comment, is unintuitive, ...). I 
> believe that this most definitely warrants a -1 as you describe because it is 
> indicative that the code, once submitted, would be hard for a future reader 
> to follow.
> 
> In my mind, the yardstick has been, and continues to be this; would a 
> reasonable person believe that the patch set as presented should be allowed 
> to merge. 
> 
> - If I can answer that question unambiguously, and unequivocally with a NO, 
> then I will score the patch with a negative score. 
> 
> - If I can answer that question unambiguously, and unequivocally with a YES, 
> then I will score the patch with a positive score. 
> 
> - For anything else, I'll use a 0.

I've run into too many cases where a "trivial" change has an
unintended consequence, so I suppose I'm more conservative with my
code reviews. I don't use 0 very often at all, not because of any
stats counting, but because I don't assume that conveys any information
to the author or other reviewers. I vote the way I mean for my
comments to be taken, so I use -1 to indicate that more work is
needed, even if that work is just explaining something better or
demonstrating that an edge case is going to be handled.

> 
> If there was a patch to make reviewstats count +0, I'd support that. But I 
> would also like to understand what the differences are between reviewstats 
> and stackalytics. Ideally I would like stackalytics to count 0's as well. If 
> you can take the time to review a patch, you should get credit for it (no 
> matter what tool is used to count). 
> 
> I would support changes to both reviewstats and stackalytics to do the 
> following.

I'm not sure where all of the interest in stats counting comes from, but
it's definitely not a motivation of my own behavior.

Doug

__
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] Please stop reviewing code while asking questions

[Clint Byrum]

Excerpts from Doug Hellmann's message of 2015-04-24 07:23:35 -0700:
> Excerpts from Julien Danjou's message of 2015-04-24 10:14:38 +0200:
> > Hi there,
> > 
> > This is now happening weekly to me now, probably because I write too
> > many patches touching almost all OpenStack projects once a cycle, and
> > I'm really tired of that behavior, so PLEASE:
> > 
> >   *Stop sending Code-Review-1 when asking a question in a patch*
> > 
> > _Sometimes_ there are good reasons to set -1 even when asking a
> > question. For example, when the question is a hint sent to the patch
> > author so that (s)he improves is commit message, a code comment or a
> > piece of code.
> > 
> > But most of the time, if you ask a question because there's something
> > YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
> > don't know the answer, so you have absolutely no right to evaluate a
> > patchset with -1. Just don't set a score, it's OK, and wait for the
> > answer before deciding if the patch is worth [-1..+2].
> > 
> > Thank you for listening, and happy hacking!
> > 
> 
> In defense of those of us asking questions, I'll just point out
> that as a core reviewer I need to be sure I understand the intent
> and wide-ranging ramifications of patches as I review them.  Especially
> in the Oslo code, what appears to be a small local change can have
> unintended consequences when the library gets out into the applications.
> 
> I will often ask questions like, "what is going to happen in X
> situation if we change this default" or "how does this change in
> behavior affect the case where Y happens, which isn't well tested
> in our unit tests." If those details aren't made clear by the commit
> message and comments in the code, I consider that a good reason to
> include a -1 with a request for the author to provide more detail.
> Often these are cases I'm not intimately familiar with, so I ask a
> question rather than saying outright that I think something is
> broken because I expect to learn from the answer but I still have
> doubts that I want to indicate with the -1.
> 

Doug I think those questions fall into the bucket of "leading, relevant
questions." These are real -1 reviews. A change that doesn't have
supporting evidence in the commit message, comments, and/or
documentation, is often a ticking time-bomb that goes off when code is
released into the wild, or sometimes much later when the what-if comes
true.

What I think Julien is frustrated by is not "what happens if ..." but "I
don't understand how this can work" or "can we really do X in library
Y?" type questions, which I've definitely seen too and have had reviews
held up for months because the -1 drops it off many reviewers' radars.

> Most of the time the author has thought about the issues and worked
> out a reason they are not a problem, but they haven't explained
> that anywhere. On the other hand, it is frequently the case that
> someone *hasn't* understood why a change might be bad and the
> question ends up leading to more research and discussion.
> 

Yes, I totally agree. Commit message is a good place to explain "why"
the change is a) needed, and b) safe. Comments and docstrings are also a
good place to explain (b), such as 

'''Mutates state in X

   No serialization is done in this method, ensure all callers lock X
   first'''

But again, asking "how does this new method ensure X mutations are
atomic?" is an awesome leading question, and nobody is frustrated about
those.

So, here's what I think is a decent rule, which we might want to put in
our reviewer checklist. I've submitted a review for wording that I think
might be appropriate.

https://review.openstack.org/177364

__
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] [metrics] what answers do you expect from counting comments? (was Re: Please stop reviewing code while asking questions)

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/24/2015 11:50 AM, Amrith Kumar wrote:

> I'm not interested in these numbers, personally (well, other than
> the usual fishing stories at summit after umpteen beers; I did 14 
> bazillion reviews in Kilo, how many did you do?).
> 
> My concern (earlier in the thread) is that there is a metric. Once 
> there's a metric someone attempts to use it to measure
> performance. And once someone uses a metric to measure performance,
> it influences behavior.
> 
> If I propose that a +0 should now get counted, given how
> overloaded the CI is, I don't want the system to get abused by
> wanton 'recheck's which start to count towards performance.

Be careful what you wish for; you just might get it... :)

If people are going to game the system, changing a rule here or there
won't stop them. Now if +0 are counted, what's to stop someone from
adding +0s to every review? It won't affect the flow, and damn, they'll
get to 14 bazillion reviews without breaking a sweat!

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVOnmUAAoJEKMgtcocwZqLpyMP/26agq1OyGLwFjQdp2tJN+yV
1nX5m5Rv/OrraFlxIUOBapbiwnT0nwoOXEiHLW/7ofIJIML7uthFi5bSt0Hynmeq
8rfRf+EEGuW0q7h4jgsBCsMD9idrn+ohsYVfqht6+P2co4kglz+VKX56EcRrm/Gx
tQO8dYZhe4ztBDe27KVwxKIAnbHSEqWCEH1PouP1/QFy0402SVtSaFfBh4FI7W8G
snHDV2aJywmNIHOoNJBanwWRLPQkxR2Z3chMVoHKMGu4T2PX8HLOeuyeSM5luEZL
ojpJad7ZZFwRlpYDZt+9hJ76rhur0btg6wbHzI6cIfMXVURWv9EXnWlqbFvTv8wc
BP7pwbbIV9MfGrlYdRSbVeXSRTXoHCLl/mUWShdx9XSbFu8Cf0E6vFjHDqA+mcF4
n0zq2SPdoQ2/C1pWRSfHj7xPjRaGIUK4gCBKdOCkKpjGSYQG77QnVShQ0ZrzN/EG
SQYyyETVNohrgEdPdoY9wUPIXyd5Jvd5vLZ0iceGDRPdI9EmO/TJjR8oElwscYpc
PKIw0c9bgKEWbVaqMNltcCFixlxUDZqSjMxskS4/Yvbd3k/i89z0ezbiI1HGawmd
+pRKD7stG4ea5a1InRaKh8Qz3qPt4Itq6yxUE2DA7F7Jav3Cfa/nGxhlWL22FzTO
LCCUva3cpOMMqgMTN09I
=0NDE
-END PGP SIGNATURE-

__
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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

[Eichberger, German]

All,

Following up from the last Neutron meeting:

If Neutron is performing an operation as an admin on behalf of a user that 
user's tenant-id (or project-id) isn't validated - in particular an admin can 
mistype and create object on behalf of non existent users. I am wondering how 
other projects (e.g. Nova) deal with that and if there is some API support in 
keystone to save us a round trip (e.g. authenticate admin + validate additional 
user-id).

Thanks,
German

__
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] [metrics] what answers do you expect from counting comments? (was Re: Please stop reviewing code while asking questions)

[Amrith Kumar]

Stefano,

I'm not interested in these numbers, personally (well, other than the usual 
fishing stories at summit after umpteen beers; I did 14 bazillion reviews in 
Kilo, how many did you do?).

My concern (earlier in the thread) is that there is a metric. Once there's a 
metric someone attempts to use it to measure performance. And once someone uses 
a metric to measure performance, it influences behavior.

If I propose that a +0 should now get counted, given how overloaded the CI is, 
I don't want the system to get abused by wanton 'recheck's which start to count 
towards performance.

Personally real metrics are things like new features, time to merge, time to 
resolve bugs and those are the kinds of things you measure in your QAR's.

My 2c worth,

-amrith

| -Original Message-
| From: Stefano Maffulli [mailto:stef...@openstack.org]
| Sent: Friday, April 24, 2015 11:58 AM
| To: openstack-dev@lists.openstack.org
| Subject: [openstack-dev] [metrics] what answers do you expect from
| counting comments? (was Re: Please stop reviewing code while asking
| questions)
| 
| On Fri, 2015-04-24 at 15:02 +, Amrith Kumar wrote:
| >
| > I would support changes to both reviewstats and stackalytics to do the
| > following.
| >
| > 1. recognizes and gives credit to '0' comments 2. identifies recheck,
| > reverify and similar directives to the CI system and flag them
| > appropriately, potentially as not being reviews but something else.
| 
| I'm intrigued by this request. In the Quarterly Activity Reports[1] I am
| more interested in time to merge (the time for a changeset to go from
| first proposal to merged), time to respond (for human interations in
| comments) and iterations (how many patchsets in a changeset).
| 
| I wonder if I should expand the scope of the reports.  Can you elaborate
| why you are interested in this sort of count?
| 
| /stef
| 
| [1]
| http://superuser.openstack.org/articles/openstack-breaks-a-new-record-for-
| active-contributors
| [1]
| http://git.openstack.org/cgit/openstack-infra/activity-
| board/plain/reports/2015-q1/pdf/2015-q1_OpenStack_report.pdf
| 
| 
| __
| 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] Mellanox request for permission for Nova CI

[Dan Smith]

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

Re: [openstack-dev] [all] Question for the TC candidates

[David Kranz]

On 04/24/2015 10:42 AM, Chris Dent wrote:

On Fri, 24 Apr 2015, Ed Leafe wrote:


I read "the downstream" to mean what you refer to as "people who
deploy workloads on them". In this context, I saw the operators as the
end-users of the work the devs do. If that gave the impression that I
don't care about people who actually run their stuff on the clouds we
build, I apologize - I was simply trying to answer what was asked.


I left the terminology intentional vague to allow people to interpret
them as they felt appropriate. To be clear I was thinking in these
sorts of ways:

* Downstream: The companies that are packaging and selling OpenStack
  in some fashion. I left these people out because I personally think
  the OpenStack project does _far_ too much to keep these people happy
  and should actually do less and since that is a somewhat
  contentious position I wanted to leave it out of the discussion (at
  least initially) as it would just muddy the waters.
Interesting. Can you list a few specific things we do as a project that 
are only for the benefit of such companies and that

you believe we should stop doing?

 -David



__
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] Please stop reviewing code while asking questions

[Jay Pipes]

On 04/24/2015 09:27 AM, Brant Knudson wrote:

On Fri, Apr 24, 2015 at 3:14 AM, Julien Danjou mailto:jul...@danjou.info>> wrote:

Hi there,

This is now happening weekly to me now, probably because I write too
many patches touching almost all OpenStack projects once a cycle, and
I'm really tired of that behavior, so PLEASE:

   *Stop sending Code-Review-1 when asking a question in a patch*

_Sometimes_ there are good reasons to set -1 even when asking a
question. For example, when the question is a hint sent to the patch
author so that (s)he improves is commit message, a code comment or a
piece of code.

But most of the time, if you ask a question because there's something
YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
don't know the answer, so you have absolutely no right to evaluate a
patchset with -1. Just don't set a score, it's OK, and wait for the
answer before deciding if the patch is worth [-1..+2].


If other developers can't understand your code then the code should be
changed to be clearer. There's no reason for OpenStack code to be so
complex that a developer can't understand it. Having code that
developers don't understand leads to bugs and sometimes security
vulnerabilties that affect our users.


This is absolutely correct, IMHO, and the reason why I always encourage 
people to ask questions about things that are unclear and point out that 
a code comment explaining the particular piece of code would be a 
welcome thing.


Now, whether or not a -1 is warranted ... meh, usually not, but if the 
code really is too difficult to decipher or the comments are 
indecipherable, sometimes a -1 is appropriate.


Best,
-jay


__
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] Question for the TC candidates

[David Lyle]

On Thu, Apr 23, 2015 at 10:14 AM, Chris Dent  wrote:



> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?



Thank you for your question.

I think the largest hurdle for quality is a lack of a unified vision and
direction for OpenStack. Without coordinated objectives for releases we
have now 19+ projects driving in scattered directions. This effects quality
on all levels. If we have a documented set of common release goals, we can
better coordinate progress and deliver on the largest pain points for
end-users and deployers. This was my hope for the Cross-Project Sessions at
the summits, but it has not been realized. The TC should drive this
coordination.

A growing ecosystem provides choice for deployers, but it also creates more
questions and uncertainty. We need to provide some guidance to deployers as
to what components are considered ready for production use and which pieces
work complimentary together. The integrated release previously served that
goal. We don't have a concrete plan moving forward to provide this
guidance. To improve quality for deployers we need to make choosing which
services to install simpler and the process to deploy and configure those
services simpler. Additionally for horizontal projects rapid ecosystem
growth creates a very difficult situation where either those horizontal
projects attempt to provide that function for all, or leave it wide open
which creates inconsistencies. This effects quality for end-users and
deployers. The TC needs to stop hand-waiving here and concretely address
the implications of this growth.

Improving the experience for developers means driving our ability to
effectively scale the development process. Progress around excising tests
from the coordinated gate begins to improve how well the gate works for
individual projects. The other central component of this is scaling the
review process. Too much frustration faces developers submitting specs and
patches. The TC needs to push targeting less bureaucracy for developers and
more toward allowing developers to contribute.

David
__
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] [metrics] what answers do you expect from counting comments? (was Re: Please stop reviewing code while asking questions)

[Stefano Maffulli]

On Fri, 2015-04-24 at 15:02 +, Amrith Kumar wrote:
> 
> I would support changes to both reviewstats and stackalytics to do the
> following.
> 
> 1. recognizes and gives credit to '0' comments
> 2. identifies recheck, reverify and similar directives to the CI
> system and flag them appropriately, potentially as not being reviews
> but something else. 

I'm intrigued by this request. In the Quarterly Activity Reports[1] I am
more interested in time to merge (the time for a changeset to go from
first proposal to merged), time to respond (for human interations in
comments) and iterations (how many patchsets in a changeset). 

I wonder if I should expand the scope of the reports.  Can you elaborate
why you are interested in this sort of count?

/stef

[1]
http://superuser.openstack.org/articles/openstack-breaks-a-new-record-for-active-contributors
[1]
http://git.openstack.org/cgit/openstack-infra/activity-board/plain/reports/2015-q1/pdf/2015-q1_OpenStack_report.pdf


__
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] [Glance][Horizon][Cinder] Kilo RC2 available

[Thierry Carrez]

Hello everyone,

Due to release-critical issues spotted in Glance, Horizon and Cinder
during RC1 testing, new release candidates were created for Kilo. The
list of RC2 fixes, as well as RC2 tarballs are available at:

https://launchpad.net/glance/kilo/kilo-rc2
https://launchpad.net/horizon/kilo/kilo-rc2
https://launchpad.net/cinder/kilo/kilo-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, these tarballs will be formally released as the final
"Kilo" versions on April 30. You are therefore strongly encouraged to
test and validate these tarballs !

Alternatively, you can directly test the stable/kilo branches at:
https://github.com/openstack/glance/tree/stable/kilo
https://github.com/openstack/horizon/tree/stable/kilo
https://github.com/openstack/cinder/tree/stable/kilo

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/glance/+filebug
or
https://bugs.launchpad.net/horizon/+filebug
or
https://bugs.launchpad.net/cinder/+filebug

and tag it *kilo-rc-potential* to bring it to the release crew's attention.

Thanks!

-- 
Thierry Carrez (ttx)


__
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] [tempest][nova] TestVolumeBootPattern fail with libvirt-xen, how to fix it?

[Anthony PERARD]

On Thu, Apr 23, 2015 at 2:42 PM, John Garbutt  wrote:
>
>
> This on a bit of the API which feels too leaky around the
> virtualisation driver chosen :(
>
> We do have a horrific hack in place so it works with the XenAPI here:
> https://github.com/openstack/nova/blob/master/nova/compute/utils.py#L136
>
> I guess its possible using that hack and tweaking the libvirt code
> could allow you to move forward with that.
>
> Longer term, we need a better way of dealing with these differences
> within the BDM code. Its possible there is something for this that I
> don't know about.

Thanks for the pointer, I will look into that.

-- 
Anthony PERARD

__
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] [tempest][nova][cinder] Tests that try to detach volumes in use

[Peter Penchev]

Hi,

There are a couple of Tempest volume tests, like
test_rescued_vm_detach_volume or test_list_get_volume_attachments,
that either sometimes[0] or always attempt to detach a volume from a
running instance while the instance could still be keeping it open.
Unfortunately, this is not completely compatible with the StorPool
distributed storage driver - in a StorPool cluster, a volume may only
be detached from a client host (the Nova hypervisor) if there are no
processes running on the host (e.g. qemu) that keep the volume open.
This came about as a result of a series of Linux kernel crashes that
we observed during our testing when a volume containing a filesystem
was detached while the kernel's filesystem driver didn't expect it to.

Right now, our driver for attaching StorPool volumes (defined in
Cinder) to Nova instances (proposed in
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/libvirt-storpool-volume-attach.html
yet didn't get enough +1/+2's in time for Kilo RC2) tries to detach
the volume, then waits for a couple of seconds, hoping that any
processes would have been notified to let it go, then tries again,
then fails.  Of course, StorPool has a "force detach" option that
could be used in that case; the problem there is that it might indeed
lead to some trouble for the instances that will have the volume
pulled out from under their tiny instance legs.  This could go in the
"let the operator handle it" category - if we're detaching a volume,
this supposedly means that the filesystem has already been unmounted
within the instance... is this a sensible approach?  Should we teach
our driver to forcibly detach the volume if the second polite attempt
still fails?

G'luck,
Peter

[0] The "sometimes" part: it seems that in some tests, like
test_list_get_volume_attachments, the order of the "detach volume" and
"stop the running instance" actions is random, dependent on the order
in which the Python test framework will execute the cleanup handlers.
Of course, it might be that I'm misunderstanding something and it is
completely deterministic and there is another issue at hand...

__
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][plugin] What should go in environment_config.yaml when no additional attributes are desired in the Fuel Web UI?

[Evgeniy L]

Hi Emma,

If you don't need additional elements on UI, just create
"environment_config.yaml" with
"{}" value for "attributes" key, i.e. "attributes: {}"

Thanks,

On Fri, Apr 24, 2015 at 6:03 PM, Emma Gordon (projectcalico.org) <
e...@projectcalico.org> wrote:

>  The fuel plugin wiki
> https://wiki.openstack.org/wiki/Fuel/Plugins#environment_config.yaml
> describes the required syntax for declaring (in the environment_config.yaml
> file) additional attributes that should appear under the Settings tab of
> the Fuel Web UI. If the only requirement is to have the check box to enable
> the plugin, but no additional attributes, what should go in this file?
>
>
>
> I’ve tried not having such a file, leaving it empty, and various variants
> of None/””/[] after ‘attributes:’, but all result in the plugin failing to
> build – the latter due to failing the test_check_env_config_attrs_fail_if_none
> test in
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/fuel_plugin_builder/tests/test_validator_v1.py.
> Is it not permitted to have no attributes? Or, if that is a reasonable use
> case, should that test not exist?
>
>
>
> Thanks,
>
> Emma
>
> __
> 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] Please stop reviewing code while asking questions

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/24/2015 10:11 AM, Morgan Fainberg wrote:

> This is really an important reason why -1 with a question cannot
> be simply "not done". If I don't understand the code, or what will
> happen in a specific case, a -1 is more useful than a no score.
> Complex code (or really clever code) is hard to maintain.

+1 for giving a -1  :)

If I don't understand the part of the code that is being patched, I
don't review it. But if I do know that part of the code and I can't
figure out what the thinking behind the patch is, I belive that a -1
is the appropriate response. I would certainly expect that for any
unclear patches I submitted.

The flip side of this, of course, is if I -1 something, I fully intend
to follow up on the patch, and if it is clarified, remove the -1. The
bigger problem is the hit-and-run approach of -1'ing a patch and then
never returning.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVOmE5AAoJEKMgtcocwZqLQXkQAKCaFJ0u4/RvPMPj5n1OCsoZ
vx3lqGshJa2aHGhiX20e9EFIBDzSTPuM06ZJdsKWsRskdK3U/is2pHP7st/PrRUu
okMUOodti8bA4ju2PNxXOKLioKakQghQf7I8E3b531m4Vx4+x7OBRHXYfe1YT8lL
asOoba9GzkGoOqqGgfI4x2wRjU63kic3dqUTtEA1ResAnX5xZYxXWj0YHS3F6N12
kmLNBDbqB9BRvF9eBVOeIKqNRQ67/D0TmnJx4zze8lJnoI8Pi2BHmQIPcnS7tv1n
jSgB6LUGh09tJ/jVyhHlFTZfnYaG4UDzOw1P7B/TNIv8yIpHZruii5NfYzGolbom
4/ZKwFMGHgvGEKoV9s/8E4TteebsQaYAYwwPrjvTdaJd67nflOJ8tdHWLhiNehLx
urhPSyzAj5lwp51r2qTCEeRoaU7l5Pjl8Sq3LSpo3FX9aFb6tLrR9oSfju6gMeBC
7UiRAYo4uXLw2GHZ5/SmoECspG0WWOD+kPKayBykknX3d1mBXkmJxBfFAADPDWv3
ymahhN1DECiKwXn8lQn3YLGqduUxPJKMhjGZLh7iIVknYHDze2CTp88VM7kxO1w/
9vyCcwvpnR7ahSE1lLkIVYHQ6HiyxD7jIP99tLx9Qfv3dKo4L0vtszcizAbJluHt
izUfXSL4t0+oPRiKbcxY
=eSbr
-END PGP SIGNATURE-

__
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] Liberty Design Summit schedule

[Thierry Carrez]

Hi everyone !

For the upcoming Liberty Design Summit in Vancouver, we'll be using a
specific sched.org website at:

https://libertydesignsummit.sched.org/

Currently it mostly contains placeholder sessions for all the project
team tracks, but PTLs should start pushing more descriptive content to
it soon. The room and time allocation, however, should in theory not
move anymore.

You will notice that this sched also includes the "keynote" and
"conference" sessions. It is so that you can produce all your Vancouver
OpenStack summit schedule in one place, rather than have to jump around
schedules.

This sched is specific for Design Summit attendees -- the general
attendance is redirected to the main conference sched[1] which does not
contain the Design Summit sessions, to avoid confusion and limit overflow.

I therefore strongly encourage all Design Summit attendees (devs and
ops) to build all their Vancouver schedule using
https://libertydesignsummit.sched.org/ !

Note that in the Design Summit sched we separated the various events so
that you can filter to see only design summit sessions by looking at:

https://libertydesignsummit.sched.org/type/design+summit

and you can point your project teams to specific track content by giving
them specific subtype URLs like:

https://libertydesignsummit.sched.org/overview/type/design+summit/Keystone

or

https://libertydesignsummit.sched.org/overview/type/design+summit/Ops

New on this design summit, some sessions may appear on multiple tracks
(like for example a "Swift: Ops feedback" session could appear on both
Swift and Ops schedules). We hope this will facilitate finding relevant
sessions in our busy schedule.

See you there !

[1] https://openstacksummitmay2015vancouver.sched.org/

-- 
Thierry Carrez (ttx)



__
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] Please stop reviewing code while asking questions

[Amrith Kumar]

And if anyone wants to take this path, I’d like to point you to two additional 
references.

https://review.openstack.org/#/c/115778/
https://github.com/openstack/trove/commit/52b78a9d87351a542441a27396d3c7c38cc2d3ce

Thanks,

-amrith

From: Brant Knudson [mailto:b...@acm.org]
Sent: Friday, April 24, 2015 11:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Please stop reviewing code while asking questions



On Fri, Apr 24, 2015 at 10:06 AM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:


On 24 April 2015 at 16:50, Chris Friesen 
mailto:chris.frie...@windriver.com>> wrote:
On 04/24/2015 07:26 AM, Salvatore Orlando wrote:
If you think it might be beneficial to adjust tooling to that these
"contributions" get counted this is fine by me. I just wanted to point out that
I do not consider those contributions at all (and btw it would be at least more
polite to put a +1 rather than a -1).

If you're asking a question to elicit information, then it's quite possible you 
don't have enough information for a +1 yet.

This makes sense in general. I was referring to the specific cases posed by 
Julien - curiosities, pedantry, or questions unrelated to the scope of the 
patch.
Julien clarified that there actually questions which grant a -1, and surely 
never a +1. For instance the kind of "what if" questions listed by Doug. In 
this case it make sense for a reviewer to put a hold a patch while waiting for 
an answer.


Would anybody be willing to codify this into a document that we can point 
offenders to so that we can get better review quality over time? Maybe 
http://docs.openstack.org/infra/manual/developers.html#peer-review (was 
https://wiki.openstack.org/wiki/ReviewChecklist ).

(Just don't be surprised when some joker posts a question with a -1 on the 
review.)

- Brant
__
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] Non-libvirt-pool image backend drivers in Liberty?

[Peter Penchev]

Hi,

During the Juno and Kilo timeframes, there was an idea to use libvirt
storage pools for the Nova image backends.  I believe that the plan
back then was to deprecate image backend drivers that do not use
libvirt storage pools in Kilo and them remove them altogether in
Liberty.  Is this still the plan?

The reason I am asking is that we (StorPool) intend to submit a
blueprint and a spec for an image backend driver that keeps the images
as separate volumes in a StorPool distributed storage cluster, so that
"migrating" them between hypervisors is just a matter of detaching
them at one side and attaching them at the other.  This would also
play nice with the StorPool Cinder integration that will hopefully
make it back in during the Liberty timeframe, so creating the images
from StorPool volumes or snapshots will also be a breeze.

Now the question is, should we try to submit our work-in-progress on
an image driver that does not use libvirt pools, or should we focus on
the StorPool integration with libvirt so that when libvirt pools hit
Nova, the StorPool image backend driver will be greatly simplified and
pretty much only concern itself with using our volume/snapshot API for
"copying" data from Cinder volumes and snapshots?  In other words,
would it be reasonable to expect that Solly Ross's great work in the
use-libvirt-storage-pools Gerrit topic will make it into Liberty, or
should we submit a spec for a separate, Ceph-like image backend
driver?

Thanks in advance for any advice, and keep up the great work!

G'luck,
Peter

__
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] Please stop reviewing code while asking questions

[Adam Young]

On 04/24/2015 04:14 AM, Julien Danjou wrote:

Hi there,

This is now happening weekly to me now, probably because I write too
many patches touching almost all OpenStack projects once a cycle, and
I'm really tired of that behavior, so PLEASE:

   *Stop sending Code-Review-1 when asking a question in a patch*


Counterpoint:  If you don't, you will not get a response from the author.

Too much information, too much churn, but a -1 demands a r response, and 
0 does not.


Perhaps if we could separately indicate a question that needs to be 
answered from a "do not merge" message,  this would changesomething 
like:



Q:  "Is Foo the bar?"  sets the question flag.

Me: "No Foo is not the bar."  Indicates that I think I have answered the 
question and clears the flag.


Q then gets notification, and can say yes or no.  If unanswered after a 
day/week, the Flag is automatically cleared.



But...that is what -1 is for.  It means: don't merge until my question 
is answered.  If an author could mark that they feel they've addressed 
the -1 without a resubmission, it would take the stink off the -1.





_Sometimes_ there are good reasons to set -1 even when asking a
question. For example, when the question is a hint sent to the patch
author so that (s)he improves is commit message, a code comment or a
piece of code.

But most of the time, if you ask a question because there's something
YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
don't know the answer, so you have absolutely no right to evaluate a
patchset with -1. Just don't set a score, it's OK, and wait for the
answer before deciding if the patch is worth [-1..+2].

Thank you for listening, and happy hacking!



__
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] Please stop reviewing code while asking questions

[Julien Danjou]

On Fri, Apr 24 2015, Doug Hellmann wrote:

> I will often ask questions like, "what is going to happen in X
> situation if we change this default" or "how does this change in
> behavior affect the case where Y happens, which isn't well tested
> in our unit tests."

Well I didn't say you weren't allowed to ask questions. I said you
cannot ask a question because you don't know something _and_ set a
score.

The cases you describe matches  my first paragraph which says:

> > _Sometimes_ there are good reasons to set -1 even when asking a
> > question. For example, when the question is a hint sent to the patch
> > author so that (s)he improves is commit message, a code comment or a
> > piece of code.

And in the case you describe I think it's even better to gently ask for
a test that proves that the case Y is not broken if the test does not
exist yet.

> If those details aren't made clear by the commit message and comments
> in the code, I consider that a good reason to include a -1 with a
> request for the author to provide more detail.

What? Why do you say this now? If I knew years ago then I would have
never have written a line of unit test! I would have replaced all of
those tests with a simple "Hey, this code totally works!" in each commit
message! ;-)

Seriously, I think this is too kind/dangerous and that's it's just even
better to ask for tests, full stop.

> Often these are cases I'm not intimately familiar with, so I ask a
> question rather than saying outright that I think something is broken
> because I expect to learn from the answer but I still have doubts that
> I want to indicate with the -1.
>
> Most of the time the author has thought about the issues and worked
> out a reason they are not a problem, but they haven't explained
> that anywhere. On the other hand, it is frequently the case that
> someone *hasn't* understood why a change might be bad and the
> question ends up leading to more research and discussion.

Yeah I don't think what you describe matches the *bad* behavior I
described in my original email.

Sorry. I can understand you wanted to appear as the bad guy I was
yelling at, but that was not you after all! ;)

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


signature.asc
Description: PGP signature
__
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] Please stop reviewing code while asking questions

[Brant Knudson]

On Fri, Apr 24, 2015 at 10:06 AM, Salvatore Orlando 
wrote:

>
>
> On 24 April 2015 at 16:50, Chris Friesen 
> wrote:
>
>> On 04/24/2015 07:26 AM, Salvatore Orlando wrote:
>>
>>  If you think it might be beneficial to adjust tooling to that these
>>> "contributions" get counted this is fine by me. I just wanted to point
>>> out that
>>> I do not consider those contributions at all (and btw it would be at
>>> least more
>>> polite to put a +1 rather than a -1).
>>>
>>
>> If you're asking a question to elicit information, then it's quite
>> possible you don't have enough information for a +1 yet.
>
>
> This makes sense in general. I was referring to the specific cases posed
> by Julien - curiosities, pedantry, or questions unrelated to the scope of
> the patch.
> Julien clarified that there actually questions which grant a -1, and
> surely never a +1. For instance the kind of "what if" questions listed by
> Doug. In this case it make sense for a reviewer to put a hold a patch while
> waiting for an answer.
>
>
Would anybody be willing to codify this into a document that we can point
offenders to so that we can get better review quality over time? Maybe
http://docs.openstack.org/infra/manual/developers.html#peer-review (was
https://wiki.openstack.org/wiki/ReviewChecklist ).

(Just don't be surprised when some joker posts a question with a -1 on the
review.)

- Brant
__
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] Please stop reviewing code while asking questions

[Jeremy Stanley]

On 2015-04-24 10:23:35 -0400 (-0400), Doug Hellmann wrote:
[...]
> I will often ask questions like, "what is going to happen in X
> situation if we change this default" or "how does this change in
> behavior affect the case where Y happens, which isn't well tested
> in our unit tests." If those details aren't made clear by the commit
> message and comments in the code, I consider that a good reason to
> include a -1 with a request for the author to provide more detail.
> Often these are cases I'm not intimately familiar with, so I ask a
> question rather than saying outright that I think something is
> broken because I expect to learn from the answer but I still have
> doubts that I want to indicate with the -1.
[...]

Thinking about this though, for the benefit of non-fluent readers
and cultures where rhetorical questions are a less common construct,
it's probably better if we make a conscious effort to actually say
what we mean and give directly actionable feedback when reviewing.

"Please add code comments here explaining the behavior in the case
where Y happens, since it isn't well tested in our unit tests." (Or
even better, "please add tests!")

A lot of the good "questions" I see in reviews where there's a -1
(and I'm frequently guilty of this too) could be much more
effectively phrased as requests to improve code comments, use
clearer syntax, add more detail in commit messages, or even better
test the code being added/changed.
-- 
Jeremy Stanley

__
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] Please stop reviewing code while asking questions

[Morgan Fainberg]

> On Apr 24, 2015, at 06:27, Brant Knudson  wrote:
> 
> 
> 
>> On Fri, Apr 24, 2015 at 3:14 AM, Julien Danjou  wrote:
>> Hi there,
>> 
>> This is now happening weekly to me now, probably because I write too
>> many patches touching almost all OpenStack projects once a cycle, and
>> I'm really tired of that behavior, so PLEASE:
>> 
>>   *Stop sending Code-Review-1 when asking a question in a patch*
>> 
>> _Sometimes_ there are good reasons to set -1 even when asking a
>> question. For example, when the question is a hint sent to the patch
>> author so that (s)he improves is commit message, a code comment or a
>> piece of code.
>> 
>> But most of the time, if you ask a question because there's something
>> YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
>> don't know the answer, so you have absolutely no right to evaluate a
>> patchset with -1. Just don't set a score, it's OK, and wait for the
>> answer before deciding if the patch is worth [-1..+2].
> 
> If other developers can't understand your code then the code should be 
> changed to be clearer. There's no reason for OpenStack code to be so complex 
> that a developer can't understand it. Having code that developers don't 
> understand leads to bugs and sometimes security vulnerabilties that affect 
> our users.
> 
> There's also be a corollary to this -- don't +1 (and especially +2) code that 
> you don't understand. In the past I've ignored changes that I wasn't going to 
> understand, typically this has been because it's implementing an external 
> standard that I'm not familiar with and don't want to spend hours reading the 
> spec. These changes tend to sit around unreviewed for a long time, so it 
> would help the submitter to make the code and reasoning clearer. So there's a 
> flip side to this -- if reviewers are going to have trouble understanding the 
> change then expect it to take a long time to merge, if it ever does.
> 

This is really an important reason why -1 with a question cannot be simply "not 
done". If I don't understand the code, or what will happen in a specific case, 
a -1 is more useful than a no score. Complex code (or really clever code) is 
hard to maintain. 

--Morgan


> Maybe it's worth it to have a job that removes -1s after some time, so the 
> reviewer will know to go back and check on it.
> 
> - Brant
> 
> __
> 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] Please stop reviewing code while asking questions

[Salvatore Orlando]

On 24 April 2015 at 16:50, Chris Friesen 
wrote:

> On 04/24/2015 07:26 AM, Salvatore Orlando wrote:
>
>  If you think it might be beneficial to adjust tooling to that these
>> "contributions" get counted this is fine by me. I just wanted to point
>> out that
>> I do not consider those contributions at all (and btw it would be at
>> least more
>> polite to put a +1 rather than a -1).
>>
>
> If you're asking a question to elicit information, then it's quite
> possible you don't have enough information for a +1 yet.


This makes sense in general. I was referring to the specific cases posed by
Julien - curiosities, pedantry, or questions unrelated to the scope of the
patch.
Julien clarified that there actually questions which grant a -1, and surely
never a +1. For instance the kind of "what if" questions listed by Doug. In
this case it make sense for a reviewer to put a hold a patch while waiting
for an answer.


>
> Chris
>
>
> __
> 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] [fuel][plugin] What should go in environment_config.yaml when no additional attributes are desired in the Fuel Web UI?

[Emma Gordon (projectcalico.org)]

The fuel plugin wiki 
https://wiki.openstack.org/wiki/Fuel/Plugins#environment_config.yaml describes 
the required syntax for declaring (in the environment_config.yaml file) 
additional attributes that should appear under the Settings tab of the Fuel Web 
UI. If the only requirement is to have the check box to enable the plugin, but 
no additional attributes, what should go in this file?

I've tried not having such a file, leaving it empty, and various variants of 
None/""/[] after 'attributes:', but all result in the plugin failing to build - 
the latter due to failing the test_check_env_config_attrs_fail_if_none test in 
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/fuel_plugin_builder/tests/test_validator_v1.py.
 Is it not permitted to have no attributes? Or, if that is a reasonable use 
case, should that test not exist?

Thanks,
Emma
__
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] Please stop reviewing code while asking questions

[Amrith Kumar]

There have been many replies on this thread, I'll just reply to this one rather 
than trying to reply piecemeal.

Doug, there's asking a question because something is unclear (implying that the 
code is needlessly complex, missing a comment, is unintuitive, ...). I believe 
that this most definitely warrants a -1 as you describe because it is 
indicative that the code, once submitted, would be hard for a future reader to 
follow.

In my mind, the yardstick has been, and continues to be this; would a 
reasonable person believe that the patch set as presented should be allowed to 
merge. 

- If I can answer that question unambiguously, and unequivocally with a NO, 
then I will score the patch with a negative score. 

- If I can answer that question unambiguously, and unequivocally with a YES, 
then I will score the patch with a positive score. 

- For anything else, I'll use a 0.

If there was a patch to make reviewstats count +0, I'd support that. But I 
would also like to understand what the differences are between reviewstats and 
stackalytics. Ideally I would like stackalytics to count 0's as well. If you 
can take the time to review a patch, you should get credit for it (no matter 
what tool is used to count). 

I would support changes to both reviewstats and stackalytics to do the 
following.

1. recognizes and gives credit to '0' comments
2. identifies recheck, reverify and similar directives to the CI system and 
flag them appropriately, potentially as not being reviews but something else. 

Thanks for reading this far,

-amrith 

| -Original Message-
| From: Doug Hellmann [mailto:d...@doughellmann.com]
| Sent: Friday, April 24, 2015 10:24 AM
| To: openstack-dev
| Subject: Re: [openstack-dev] Please stop reviewing code while asking
| questions
| 
| Excerpts from Julien Danjou's message of 2015-04-24 10:14:38 +0200:
| > Hi there,
| >
| > This is now happening weekly to me now, probably because I write too
| > many patches touching almost all OpenStack projects once a cycle, and
| > I'm really tired of that behavior, so PLEASE:
| >
| >   *Stop sending Code-Review-1 when asking a question in a patch*
| >
| > _Sometimes_ there are good reasons to set -1 even when asking a
| > question. For example, when the question is a hint sent to the patch
| > author so that (s)he improves is commit message, a code comment or a
| > piece of code.
| >
| > But most of the time, if you ask a question because there's something
| > YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
| > don't know the answer, so you have absolutely no right to evaluate a
| > patchset with -1. Just don't set a score, it's OK, and wait for the
| > answer before deciding if the patch is worth [-1..+2].
| >
| > Thank you for listening, and happy hacking!
| >
| 
| In defense of those of us asking questions, I'll just point out that as a
| core reviewer I need to be sure I understand the intent and wide-ranging
| ramifications of patches as I review them.  Especially in the Oslo code,
| what appears to be a small local change can have unintended consequences
| when the library gets out into the applications.
| 
| I will often ask questions like, "what is going to happen in X situation
| if we change this default" or "how does this change in behavior affect the
| case where Y happens, which isn't well tested in our unit tests." If those
| details aren't made clear by the commit message and comments in the code,
| I consider that a good reason to include a -1 with a request for the
| author to provide more detail.
| Often these are cases I'm not intimately familiar with, so I ask a
| question rather than saying outright that I think something is broken
| because I expect to learn from the answer but I still have doubts that I
| want to indicate with the -1.
| 
| Most of the time the author has thought about the issues and worked out a
| reason they are not a problem, but they haven't explained that anywhere.
| On the other hand, it is frequently the case that someone *hasn't*
| understood why a change might be bad and the question ends up leading to
| more research and discussion.
| 
| Doug
| 
| __
| 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] TC candidacy

[Tristan Cacqueray]

Hi Edgar,

To make it clear, this candidacy can not be confirmed as it was received
after the deadline (April 23, 05:59 UTC).

Regards,
Tristan

On 04/24/2015 02:55 AM, Edgar Magana wrote:
> OpenStack Members,
> 
> I would like to announce my candidacy to serve for first time on the 
> Technical Committee.
> 
> Objective:
> 
> I want to be part of the Technical Committee (TC) because I have all the 
> passion in the world for OpenStack and I want to keep dedicating my energy 
> and love to the most revolutionary opensource project of the last decade. I 
> want to make OpenStack the best platform from the software perspective but 
> also from the interconnectivity and operability sides as well.
> 
> Experience:
> 
> I have been member of OpenStack since April 2011, when I attended my first 
> summit in Santa Clara and since then I haven't missed one of them and I do 
> not want to do it! I am also part of the Neutron core team since 2012, 
> currently focus on getting ready the first OpenStack Networking Guide! Thanks 
> to all the support from the members of the Docs, Neutron and other teams. I 
> like to document everything about OpenStack deployments and best practices 
> for operability, some of my guides are referenced even by big companies like 
> Red Hat: https://www.rdoproject.org/Install#Installation
> 
> Vision:
> 
> I have spent many hours operating and developing OpenStack and I think it can 
> be better and better. It needs the right direction and the right support 
> without having vendor-specific interest impacting the future of the platform. 
> I want to bring the view of the operators to the TC. I want to give all this 
> passion and energy to this committee to ensure that we all going to keep 
> having all those great discussions every six months and many companies will 
> keep transitioning their Data Centers ADNs to be powered by OpenStack.
> 
> Leading one of the most challenging OpenStack adoption in the Operators side 
> has given me the experience to guide the TC and the Foundation to the most 
> demanding areas in order to guarantee the growing of the teams and our 
> community.
> 
> Sincerely,
> 
> Edgar Magana
> -
> IRC: emagana
> Mail: emag...@gmail.com
> Github: https://github.com/emagana
> 
> 
> 
> __
> 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
> 




signature.asc
Description: OpenPGP digital signature
__
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] Please stop reviewing code while asking questions

[Chris Friesen]

On 04/24/2015 07:26 AM, Salvatore Orlando wrote:


If you think it might be beneficial to adjust tooling to that these
"contributions" get counted this is fine by me. I just wanted to point out that
I do not consider those contributions at all (and btw it would be at least more
polite to put a +1 rather than a -1).


If you're asking a question to elicit information, then it's quite possible you 
don't have enough information for a +1 yet.


Chris

__
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] [neutron] Need guidance - functional tests and rootwrap

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/24/2015 04:02 PM, Ihar Hrachyshka wrote:
> On 04/24/2015 03:48 PM, Paul Michali wrote:
>> Hi, I'm floundering a bit, and could use some guidance on
>> this...
> 
>> For the neutron-vpnaas repo, I am trying to modify the
>> functional jobs (dsvm-functional and dsvm-functional-sswan) to
>> act in a similar manner to neutron, where devstack is configured,
>> but no stacking is performed.
> 
>> I'm trying to do the same thing and have the jobs doing the 
>> configuration only. Side note: there are two jobs, because there 
>> are currently two reference implementations of VPN drivers, each
>> of which require a different IPSec package installed.
> 
>> As part of this setup, in tox.ini, the neutron
>> deploy_rootwrap.sh script is called which places the rootwrap
>> filters and config file in the repo's
>> .tox/dsvm-functional/etc/neutron/ area (or 
>> ./tox/dsvm-functional-sswan/etc/neutron/).
> 
>> Now, the issue I see is that tests trying to run "ip" commands, 
>> are failing saying that the config file is invalid:
> 
>> ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-] 
>> Incorrect configuration file: /etc/neutron/rootwrap.conf
> 
>> As you can see, this is trying to access the rootwrap.conf in 
>> /etc/neutron and not the one in 
>> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functioanl-sswan/etc/neutron/
.
>
>>  For Neutron, how is the dsvm-functional job directing the 
>> rootwrap daemon to use the files in the repo's .tox area?
> 
> It may be the case that oslo_config.cfg.find_config_files is
> involved, doing its dirty config file autodiscovery job. May I ask
> you to try out [1] that is designed to avoid it, and report back
> with the result?
> 
> [1]:
> https://review.openstack.org/#/c/172354/1/neutron/tests/base.py
> 

Nah, that won't help for rootwrap. It does not even rely on
oslo.config, and the config file is passed with CLI args. I recommend
checking what's cfg.CONF.AGENT.root_helper_daemon value inside your
failing test cases to see whether tox properly passed
OS_ROOTWRAP_DAEMON_CMD, with {envdir} properly substituted.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVOlbTAAoJEC5aWaUY1u57zkgH+wa5yvVYqglN+B7qpkIfR5QB
5X+6fh9O2KNV8qkDkSKwfRgqs8UouNGOO39zYcgG/QOlqfRKv9ROGkLyNzRihaRg
ynmDSiXVSiW/wnW+R8ymBSFiU30O88jtlBxlwYYUlz1pdbdQxpVUWPspvYrYU95O
zdBkifNEvDpYhb/DySq6dlOJB+VQ2IlnCsBhkZeiKQz/T2fnYDoTNZ05beLZez2s
kntPkYXG11dYRDYQxF76A3fFSboiy2TkX7wl8wK29WQI350gk3Fc/ob0QlMYR0Kf
IcvEHh+g7cvkZkcX3vn3dDTnI9WUorDUjvnvfw8PGvJaB/edniUBjSC6HHmhBv8=
=Pg+J
-END PGP SIGNATURE-

__
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] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?

[Mathieu Rohon]

Hi loy, thanks for this dedicated thread.

On Fri, Apr 24, 2015 at 3:13 PM, Kyle Mestery  wrote:

> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe  wrote:
>
>> It's already away from the original thread, so I start this new one,
>> also with some extra tag because I think it touch some corss-project
>> area.
>>
>> Original discuss and reference:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html
>>
>> https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst
>>
>> Background summary:
>> All in-tree implementation would be splitted from Openstack
>> networking, leaving Neutron as a naked "API/DB" platform, with a list
>> of out-tree implementation git repos, which are not maintained by core
>> team any more, but may be given a nominal "big tent" under the
>> Openstack umbrella.
>>
>>
> I'm not sure what led you to this discussion, but it's patently incorrect.
> We're going to split the in-tree reference implementation into a separate
> git repository. I have not said anything about the current core revewier
> team not being responsible for that. It's natural to evolve to a core
> reviewer team which cares deeply about that, vs. those who care deeply
> about the DB/API layer. This is exactly what happened when we split out the
> advanced services.
>
>
>> Motivation: a) Smaller core team only focus on the in-tree API/DB
>> definition, released from concrete controlling function
>> implementation; b) If there is official implementation inside Neutron,
>> 3rd external SDN controller would face the competition.
>>
>> I'm not sure whether it's exactly what cloud operators want the
>> Openstack to deliver. Do they want a off-the-shelf package, or just a
>> framework and have to take the responsibility of integrating with
>> other external controlling projects? A analogy with Linux that only
>> kernel without any device driver has no use at all.
>>
>>
> We're still going to deliver ML2+OVS/LB+[DHCP, L3, metadata] agents for
> Liberty. I'm not sure where your incorrect assumption on what we're going
> to deliver is coming from.
>
>
>> There are already many debates about nova-network to Neutron parity.
>> If largely used OVS and LB driver is out of tree and has to be
>> integrated separately by customers, how do those they migrate from
>> nova network? Standalone SDN controller has steep learning curve, and
>> a lot of users don't care which one is better of ODL vs. OpenContrail
>> to be integrated, they just want Openstack package easy to go by
>> default in tree implementation,  and are ready to drive all kinds of
>> opensource or commercial backends.
>>
>>
> Do you realize that ML2 is plus the L2 agent is an SDN controller already?
>

I totally agree that this part of Neutron should be considered as a SDN
controller. Actually we can even say that the Neutron SDN controller is
composed of ML2+ref service plugins+agents.
I think this thread is also motivated by the fact that, during design
summit,  we keep on earing that Neutron should NOT deliver and maintain a
SDN controller, and it should rely on 3rd party SDN controllers.


>
>> BTW: +1 to henry and mathieu, that indeed Openstack is not responsible
>> projects of switch/router/fw, but it should be responsible for
>> scheduling, pooling, and driving of those backends, which is the same
>> case with Nova/Cinder scheduler and compute/volume manager. These
>> controlling functions shouldn't be classified as backends in Neutron
>> and be splitted out of tree.
>>
>
>
>> Regards
>>
>>
>> On Fri, Apr 24, 2015 at 2:37 AM, Kyle Mestery 
>> wrote:
>> >
>> >
>> > On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M 
>> wrote:
>> >>
>> >> Yeah. In the end, its what git repo the source for a given rpm you
>> install
>> >> comes from. Ops will not care that neutron-openvswitch-agent comes
>> from repo
>> >> foo.git instead of bar.git.
>> >>
>> >
>> >
>> > That's really the tl;dr of the proposed split.
>> >
>> > Thanks,
>> > Kyle
>> >
>> >>
>> >> Thanks,
>> >> Kevin
>> >> 
>> >> From: Armando M. [arma...@gmail.com]
>> >> Sent: Thursday, April 23, 2015 9:10 AM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron
>> backend
>> >> code
>> >>
>> 
>> >>> I agree with henry here.
>> >>> Armando, If we use your analogy with nova that doesn't build and
>> deliver
>> >>> KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
>> >>> driver and an agent which manage OVS, just like nova which provides a
>> driver
>> >>> to manage libvirt/KVM.
>> >>> Moreover, external SDN controllers are much more complex than Neutron
>> >>> with its reference drivers. I feel like forcing the cloud admin to
>> deploy
>> >>> and maintain an external SDN controller would be a terrible
>> experience for
>> >>> him if he just needs a simple way manage connectivity between VMs.
>> >>> At the end of the day, it might be detrimental for th

Re: [openstack-dev] Please stop reviewing code while asking questions

[Dan Smith]

> In defense of those of us asking questions, I'll just point out
> that as a core reviewer I need to be sure I understand the intent
> and wide-ranging ramifications of patches as I review them.  Especially
> in the Oslo code, what appears to be a small local change can have
> unintended consequences when the library gets out into the applications.
> 
> I will often ask questions like, "what is going to happen in X
> situation if we change this default" or "how does this change in
> behavior affect the case where Y happens, which isn't well tested
> in our unit tests." If those details aren't made clear by the commit
> message and comments in the code, I consider that a good reason to
> include a -1 with a request for the author to provide more detail.
> Often these are cases I'm not intimately familiar with, so I ask a
> question rather than saying outright that I think something is
> broken because I expect to learn from the answer but I still have
> doubts that I want to indicate with the -1.
> 
> Most of the time the author has thought about the issues and worked
> out a reason they are not a problem, but they haven't explained
> that anywhere. On the other hand, it is frequently the case that
> someone *hasn't* understood why a change might be bad and the
> question ends up leading to more research and discussion.

Right, and -1 makes the comment much more visible to both other cores
and the reviewer. Questions which rightly point out something which
would lead to what the OP considers a legit -1 can *easily* get missed
in the wash of review comments on a bug.

If you leave a -1 for a question and never come back to drop it when the
answer is provided, then that's bad and you should stop doing that.
However, I'm really concerned about the suggestion to not -1 for
questions in general because of the visibility we lose. I also worry
that more non-core people will feel even less likely to -1 a patch for
something they feel is just their failing to understand, when in fact
it's valuable feedback that the code is obscure.

As a core, I don't exclude all reviews with a -1, and doing so is pretty
dangerous behavior, IMHO.

I'm not sure if the concern of -1s for questions is over dropping the
review out of the hitlist for cores, or if it's about hurting the
feelings of the submitter. I'm not in favor of discouraging -1s for
either problem.

--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

Re: [openstack-dev] [all] Question for the TC candidates

[Chris Dent]

On Fri, 24 Apr 2015, Ed Leafe wrote:


I read "the downstream" to mean what you refer to as "people who
deploy workloads on them". In this context, I saw the operators as the
end-users of the work the devs do. If that gave the impression that I
don't care about people who actually run their stuff on the clouds we
build, I apologize - I was simply trying to answer what was asked.


I left the terminology intentional vague to allow people to interpret
them as they felt appropriate. To be clear I was thinking in these
sorts of ways:

* Downstream: The companies that are packaging and selling OpenStack
  in some fashion. I left these people out because I personally think
  the OpenStack project does _far_ too much to keep these people happy
  and should actually do less and since that is a somewhat
  contentious position I wanted to leave it out of the discussion (at
  least initially) as it would just muddy the waters.

* End-users: Someone who might run 'nova boot' or 'heat stack-create'
  or the openstack client or horizon to get something going. I have
  access to clouds where I do this, but I do not operate them (I do,
  however, operate my own little mini clouds at home).

* Operators: People responsible for making sure one or more cloud
  installations exist and/or are running smoothly.

* Developers: The people writing and testing the code.

Some individuals will have one of these roles, some will have more.

Some individuals will have entirely different definitions. That's
cool.

Thanks to everyone for participating. It's been very useful I think.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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] What's Up Doc? Apr. 24 2015

[Anne Gentle | Just Write Click]

__Redirect madness (March madness was over too soon)__
Sorry to bring down the docs site for a while (in my overnight) earlier 
today. Thanks to Sean Dague and Andreas Jaeger for quick help. We now have 
three of us with the ability to fix it quickly without waiting for builds 
to finish. Our hope is to get off of FTP dependence next release and move 
to object store (swift) for the site next release. 

You may still see oddities around the /trunk /draft moves in Google 
searches, but I am already seeing top hits changing for the End User Guide 
and Admin User Guide, so I expect we're out of the woods.

__Kilo release: cutting a stable branch__
I would love to cut a stable/kilo branch a week from today, but of course 
we always evaluate day-by-day, week-by-week on the completeness of the 
Configuration Reference and Install Guides.

__Networking Guide sprint and Bug Triage day 4/23__
Thanks to those who could help out for the sprint and bug triage day. 
Really appreciate the thoughtfulness on this day about doc bugs. While our 
numbers didn't budge much for openstack-manuals, the downward trend in 
openstack-api-site this release has been impressive, dang. Thanks Diane 
especially for the diligence in bug fixes. Check out 
http://webnumbr.com/untouched-bugs-in-openstack-api-site. 

__First App Tutorial__
Good progress on cleanup patches for the First App Tutorial. We'll publish 
on developer.openstack.org once it's sufficiently edited.

__Doc team meeting__

We met this week, see the minutes here to catch up:
http://eavesdrop.openstack.org/meetings/docteam/2015/docteam.2015-04-22-14.00.html

We want to switch to a different meeting schedule; alternating weeks rather 
than first/third, second/fourth. Please weigh in on times for the new 
schedule.

__Liberty Design Summit__
Be sure to put your ideas in the etherpad at 
https://etherpad.openstack.org/p/Docs_Liberty_Design_Sessions 
Lana will fit those into the schedule at 
https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?usp=sharing
 
and we'll see you in Vancouver! 

-- 
Anne Gentle
annegen...@justwriteclick.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] [TaskFlow] trying to understand taskflow persistence backend

[Doug Hellmann]

Excerpts from Sumit Jamgade's message of 2015-04-24 13:17:41 +:
> Hi,
> Is there some place where I can read up how taskflow uses database for 
> persistance.Some kind of highlevel flow. 
> 
> I am trying to read up the code, but some guidelines at arch level will be 
> helpfull.
> Thanks.--sj

The documentation for taskflow is at
http://docs.openstack.org/developer/taskflow/

I don't know if what you're looking for is there, but taskflow is one of
our better documented libraries, so if it's not there it may not have
been written down yet. :-)

Doug


__
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] Please stop reviewing code while asking questions

[Doug Hellmann]

Excerpts from Julien Danjou's message of 2015-04-24 10:14:38 +0200:
> Hi there,
> 
> This is now happening weekly to me now, probably because I write too
> many patches touching almost all OpenStack projects once a cycle, and
> I'm really tired of that behavior, so PLEASE:
> 
>   *Stop sending Code-Review-1 when asking a question in a patch*
> 
> _Sometimes_ there are good reasons to set -1 even when asking a
> question. For example, when the question is a hint sent to the patch
> author so that (s)he improves is commit message, a code comment or a
> piece of code.
> 
> But most of the time, if you ask a question because there's something
> YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
> don't know the answer, so you have absolutely no right to evaluate a
> patchset with -1. Just don't set a score, it's OK, and wait for the
> answer before deciding if the patch is worth [-1..+2].
> 
> Thank you for listening, and happy hacking!
> 

In defense of those of us asking questions, I'll just point out
that as a core reviewer I need to be sure I understand the intent
and wide-ranging ramifications of patches as I review them.  Especially
in the Oslo code, what appears to be a small local change can have
unintended consequences when the library gets out into the applications.

I will often ask questions like, "what is going to happen in X
situation if we change this default" or "how does this change in
behavior affect the case where Y happens, which isn't well tested
in our unit tests." If those details aren't made clear by the commit
message and comments in the code, I consider that a good reason to
include a -1 with a request for the author to provide more detail.
Often these are cases I'm not intimately familiar with, so I ask a
question rather than saying outright that I think something is
broken because I expect to learn from the answer but I still have
doubts that I want to indicate with the -1.

Most of the time the author has thought about the issues and worked
out a reason they are not a problem, but they haven't explained
that anywhere. On the other hand, it is frequently the case that
someone *hasn't* understood why a change might be bad and the
question ends up leading to more research and discussion.

Doug

__
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] [neutron][docs] config reference updates

[Gauvain Pocentek]

As you may know, the doc team generates docbook tables listing the 
configuration options for some OpenStack projects, including Neutron. 
This tables are used in the configuration reference. I've updated these 
tables in preparation for the Kilo release, but with the move of plugin 
to external repositories it's getting very complicated for the doc team 
to make sure that everything is listed and properly categorized.


Could driver developers check that the tables generated in 
https://review.openstack.org/177283 are correct?


The easiest way to validate that nothing's missing is to have a look at 
the neutron.flagmapping file, which is supposed to list all the 
available config options, along with the associated categories.


Thanks,

Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.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-dev] [Manila] Kilo RC2 available

[Ben Swartzlander]

Hello everyone,

The RC2 tarball is ready. This includes a bugfix for the NetApp driver 
as well as some requirements changes.


https://launchpad.net/manila/kilo/kilo-rc2

Unless release-critical issues are found that warrant a release 
candidate respin, these RC2 will be formally released as the 2015.1.0 
final version on April 30. You are therefore strongly encouraged to test 
and validate the tarball!


Alternatively, you can directly test the stable/kilo branche at:
https://github.com/openstack/manila/tree/stable/kilo

If you find an issue that could be considered release-critical, please 
file it at:


https://bugs.launchpad.net/manila/+filebug

and tag it *kilo-rc-potential* to bring it to the core team's attention.

-Ben Swartzlander

__
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] [Nova]Devstack live migration.

[kk bk]

Are you sure ?. I had few debugs on migrate_server of conductor/manager.py,
it did not show up on n-api.log. Pls note, i did restart n-api to.

1) I am looking at the right process ?. Should i look somewhere else ?

2) Also, can you point me to the code where the context is actually
set for cctxt.call(context,
'migrate_server', **kw)

-KK
__
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] [Heat] [Keystone] Heat cfn-push-stats failed with '403 SignatureDoesNotMatch', it may be Keystone problem.

[Adam Young]

On 08/24/2014 01:55 AM, Yukinori Sagara wrote:

Can you please submit this patch to Gerrit.  Taking it off the mailing 
list without a signed contributors agreement is problematic.




Hi.


I am trying Heat instance HA, using RDO Icehouse.

After instance boot, instance push own stats to heat alarm with 
cfn-push-stats command.


But cfn-push-stats always failed with error '403 
SignatureDoesNotMatch', this message is


output to /var/log/cfn-push-stats.log.


I debugged client and server side code. (i.e. cfn-push-stats, boto, 
heat, keystone,


keystoneclient) And I found curious code mismatch between boto and 
keystoneclient about


signature calculation.


Here is a result of debugging, and code examination.


* Client side

cfn-push-stats uses heat-cfntools library, and heat-cfntools do 'POST' 
request with boto.


boto perfomes signature calculation. [1]

for signature calculation, firstly it construct 'CanonicalRequest', 
some strings are joined.


And create a digest hash of the CanonicalRequest for signature 
calculation.


CanonicalRequest contains CanonicalQueryString, which is transfomed 
URL query strings.



CanonicalRequest =

  HTTPRequestMethod + '\n' +

  CanonicalURI + '\n' +

  CanonicalQueryString + '\n' +

  CanonicalHeaders + '\n' +

  SignedHeaders + '\n' +

  HexEncode(Hash(RequestPayload))


**AWS original tool (aws-cfn-bootstrap-1.4) and boto uses empty string as

CanonicalQueryString, when request is POST.**


AWS original tool's code is following.


cfnbootstrap/aws_client.py

110 class V4Signer(Signer):


144 (canonical_headers, signed_headers) = 
self._canonicalize_headers(new_headers)


145 canonical_request += canonical_headers + '\n' + 
signed_headers + '\n'


146 canonical_request += 
hashlib.sha256(self._construct_query(params).encode('utf-8') if verb 
== 'POST' else '').hexdigest()



boto's code is following.


boto/auth.py

283 class HmacAuthV4Handler(AuthHandler, HmacKeys):


393 def canonical_request(self, http_request):

394 cr = [http_request.method.upper()]

395 cr.append(self.canonical_uri(http_request))

396 cr.append(self.canonical_query_string(http_request))

397 headers_to_sign = self.headers_to_sign(http_request)

398 cr.append(self.canonical_headers(headers_to_sign) + '\n')

399 cr.append(self.signed_headers(headers_to_sign))

400 cr.append(self.payload(http_request))

401 return '\n'.join(cr)


337 def canonical_query_string(self, http_request):

338 # POST requests pass parameters in through the

339 # http_request.body field.

340 if http_request.method == 'POST':

341 return ""

342 l = []

343 for param in sorted(http_request.params):

344 value = 
boto.utils.get_utf8_value(http_request.params[param])


345 l.append('%s=%s' % (urllib.quote(param, safe='-_.~'),

346 urllib.quote(value, safe='-_.~')))

347 return '&'.join(l)


* Server side

heat-api-cfn queries to keystone in order to check request authorization.

keystone uses keystoneclient to check EC2 format request signature.


In here, **keystoneclient uses (non-empty) query string as 
CanonicalQueryString, even


though request is POST.**

And create a digest hash of the CanonicalRequest for signature 
calculation.



keystoneclient's code is following.


keystoneclient/contrib/ec2/utils.py

 28 class Ec2Signer(object):


154 def _calc_signature_4(self, params, verb, server_string, path, 
headers,


155   body_hash):

156 """Generate AWS signature version 4 string."""


235 # Create canonical request:

236 # http://docs.aws.amazon.com/general/latest/gr/

237 # sigv4-create-canonical-request.html

238 # Get parameters and headers in expected string format

239 cr = "\n".join((verb.upper(), path,

240 self._canonical_qs(params),

241 canonical_header_str(),

242 auth_param('SignedHeaders'),

243 body_hash))


125 @staticmethod

126 def _canonical_qs(params):

127 """Construct a sorted, correctly encoded query string as 
required for


128 _calc_signature_2 and _calc_signature_4.

129 """

130 keys = list(params)

131 keys.sort()

132 pairs = []

133 for key in keys:

134 val = Ec2Signer._get_utf8_value(params[key])

135 val = urllib.parse.quote(val, safe='-_~')

136 pairs.append(urllib.parse.quote(key, safe='') + '=' + val)

137 qs = '&'.join(pairs)

138 return qs


So it should be different from boto(client side) to 
keystoneclient(server side),


cfn-push-stats always fails with error log '403 SignatureDoesNotMatch' 
in such reason.



I wrote a patch to resolve how to treat CanonicalQueryString mismatch,

My patch honored AWS original tool and boto, so if request is POST,

'CanonicalQueryString' i

Re: [openstack-dev] [all] Question for the TC candidates

[Dean Troyer]

On Thu, Apr 23, 2015 at 11:14 AM, Chris Dent  wrote:

> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?



One thing that I see as an indicator of quality is how a system fits
together.  Does it feel like a well-designed cohesive unit or a collection
of individually well-designed parts?  Current indications are that
OpenStack feels to most people like a collection of parts.

I believe it is the TC's responsibility to facilitate and encourage the
cross-project communication required to achieve a cohesive whole.  Work is
already being done with this goal in mind, for example Thierry leads a
weekly cross-project meeting for exactly this purpose, to facilitate
communication between projects.  I do think he is wearing his Release
Manager hat then, but that further illustrates that it is not the TC that
need to be doing the work, but they should be setting the direction and
expectations, and providing a framework within which to operate.

With all of the talk about the TC needing to 'get out of the way', I also
believe that one of the responsibilities it has in technical leadership is
to make some hard decisions when something is not working.  I know I
sometimes have difficulty knowing when a project I am working on is going
nowhere because I am too close to it.  I need someone with perspective to
let me know what I can not see for myself.  To put it into the Big Tent
metaphor, someone has to occasionally clean the elephant poo out of the
tent.  Fortunately this has been a rare event so far in OpenStack's
history, but the opening of the tent flaps changes that activity from an
up-front one to an after-the-fact one and the TC must not forget that
building a quality product is both including quality parts and assemblies,
and removing the lesser quality ones.

As I said before, the majority of my time with OpenStack has been in
cross-project activities and I get a first-hand taste of what people have
to do to work with it.  It is not pretty.  There already are working groups
addressing two of the most glaring inconsistent areas: APIs and log files.
The TC role here is to encourage and support these groups and prompt others
to form where they will be able to do good work.  I have staked my future
with OpenStack to two areas that both need this attention and I work every
day to provide frameworks for developers and those wanting to do
small-scale exercises, and for deployers and end-users who need to actually
use an OpenStack cloud.  I think that the next level for that vision is
strengthen that from within the TC itself.


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] [neutron] Need guidance - functional tests and rootwrap

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/24/2015 03:48 PM, Paul Michali wrote:
> Hi, I'm floundering a bit, and could use some guidance on this...
> 
> For the neutron-vpnaas repo, I am trying to modify the functional
> jobs (dsvm-functional and dsvm-functional-sswan) to act in a
> similar manner to neutron, where devstack is configured, but no
> stacking is performed.
> 
> I'm trying to do the same thing and have the jobs doing the 
> configuration only. Side note: there are two jobs, because there
> are currently two reference implementations of VPN drivers, each of
> which require a different IPSec package installed.
> 
> As part of this setup, in tox.ini, the neutron deploy_rootwrap.sh
> script is called which places the rootwrap filters and config file
> in the repo's .tox/dsvm-functional/etc/neutron/ area (or 
> ./tox/dsvm-functional-sswan/etc/neutron/).
> 
> Now, the issue I see is that tests trying to run "ip" commands,
> are failing saying that the config file is invalid:
> 
> ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-]
> Incorrect configuration file: /etc/neutron/rootwrap.conf
> 
> As you can see, this is trying to access the rootwrap.conf in 
> /etc/neutron and not the one in 
> /opt/stack/new/neutron-vpnaas/.tox/dsvm-functioanl-sswan/etc/neutron/.
>
>  For Neutron, how is the dsvm-functional job directing the
> rootwrap daemon to use the files in the repo's .tox area?

It may be the case that oslo_config.cfg.find_config_files is involved,
doing its dirty config file autodiscovery job. May I ask you to try
out [1] that is designed to avoid it, and report back with the result?

[1]: https://review.openstack.org/#/c/172354/1/neutron/tests/base.py

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVOkzoAAoJEC5aWaUY1u57FCMIAJbC3lykBHbEvH//ptsFk5EZ
dCaO3HCvc1vucE1H16gQZMa0NIiaMPz6qo+iWMGpUVMhNh1Eh3NUcXThIemXt2jc
zEvN0Tj1pihWAjOawMhzUMm1lQljj8xpIhXwSTV9fLrXdYlqKgqTiixyTmX3Ef/X
P/cyV3SMs25GwtGDe1cU04+CftCtVZCrNx0WkiPw1r+ES82wwghpzpKu+o0q0eyN
mu6Y6AtrE14rRVg5JCXjtQNih8hcPGMQQseRyr4mBqLC3Ja1qqR/TIut+fMjsM2U
q27VyF89TrjGOSOdqFbxcYEv6r7NHDpKTBGVUJM4sHAPdzO20Cn3Hu1mJ2b0D4s=
=ymLu
-END PGP SIGNATURE-

__
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] Question for the TC candidates

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/24/2015 08:30 AM, Zane Bitter wrote:

>> I'm not sure what you see as the difference between the "end 
>> users" and the "operators" of OpenStack, because in my mind they 
>> are one and the same. I don't consider the people using, say, 
>> public cloud services to be OpenStack end users, because
>> ultimately they just want stuff that works, and if it doesn't,
>> they'll blame the provider, not OpenStack. I see our end users as
>> the people who deploy and run OpenStack clouds.
> 
> Whoa! Back the terminology train up.
> 
> There's been longstanding confusion whenever anyone mentions the 
> word "users" because it is ambiguous whether it refers to the
> people who deploy OpenStack clouds or the people who deploy
> workloads on them. This has largely been resolved by a conscious
> effort to refer to the two groups as "operators" and "end users"
> respectively.
> 
> The *last* thing we need is to muddy the waters again since,
> contrary to your (I hope inadvertent) implication, both groups are
> important and they often have different (and occasionally
> conflicting) interests. The qualifier "end" is there for a reason;
> don't ignore it.

Well, of course they are important, and shouldn't be ignored, but the
question explicitly stated:

> I'm concerned with are the developers, end-users and operators of 
> OpenStack: the individuals who are actively involved with it on a 
> daily basis. I'm intentionally leaving out things like "the 
> downstream".

I read "the downstream" to mean what you refer to as "people who
deploy workloads on them". In this context, I saw the operators as the
end-users of the work the devs do. If that gave the impression that I
don't care about people who actually run their stuff on the clouds we
build, I apologize - I was simply trying to answer what was asked.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVOkqtAAoJEKMgtcocwZqLkhEQAJub3Ae6+4/8Cf08kiB8vTd4
f3U8s7SOnfP371Jv72F1QbA1Ar4qSL7eTQF2/aybMpnNx9zIIE/DD6x52l1qmREm
fCis2CrxlhzFlS5cx7IQipmJlo+DtiPT9dUS+FfeMoy1zuLojFFGIUt11bgW6uiK
9JpP1VDCS16PxdclfpPr1a36LIppU2Izr4d/Yxrl/N3Xnk8zPMNTBISHptoMSNNZ
lme/Txm5D9wY3UVTivvxx39mGtP74whMTeqrvJflrJGs9hXBGHu197JzuNhvL/8N
tVGFl2rikaDmQJOFC0N37lj59512Ch6pvfMoIJQB+ppWs+6nqgp4NB8gF/Z+IcDi
+qwpe2LWT4qluQ7h4k/2V/t2elhmxrZMEMJIOm+azAh+KmotyLbckC1D2tkuELLP
07JyKwmLxAPyquT6OsruU1i57xdTCIM9TN1G78IcfSGlaN90oHOhPQxfvL6Xz/+N
SERxxlJjt/ofb9tU2UFBNPHEIKbgwHmBiYFr3NkG8FXb55abCUVX51d/4vg+iChO
k8KKUmyY7Ny4vPmQXMBUnojOUnMxhpfV4kuBtRLOcn3hGq66xKJ+oeb6S9SC0bZV
ylDXagHzPKjZSfzwRBg/DohNVPVImWNG7qFpfyt/o3Biy0ZW1YaDdSBBZiBaKXZ+
YTRS4fizC4ASrKg1imoL
=xR9N
-END PGP SIGNATURE-

__
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] [neutron] Need guidance - functional tests and rootwrap

[Paul Michali]

Hi,
I'm floundering a bit, and could use some guidance on this...

For the neutron-vpnaas repo, I am trying to modify the functional jobs
(dsvm-functional and dsvm-functional-sswan) to act in a similar manner to
neutron, where devstack is configured, but no stacking is performed.

I'm trying to do the same thing and have the jobs doing the configuration
only. Side note: there are two jobs, because there are currently two
reference implementations of VPN drivers, each of which require a different
IPSec package installed.

As part of this setup, in tox.ini, the neutron deploy_rootwrap.sh script is
called which places the rootwrap filters and config file in the repo's
.tox/dsvm-functional/etc/neutron/ area (or
./tox/dsvm-functional-sswan/etc/neutron/).

Now, the issue I see is that tests trying to run "ip" commands, are failing
saying that the config file is invalid:

ERROR neutron_vpnaas.services.vpn.common.netns_wrapper [-] Incorrect
configuration file: /etc/neutron/rootwrap.conf

As you can see, this is trying to access the rootwrap.conf in /etc/neutron
and not the one in
/opt/stack/new/neutron-vpnaas/.tox/dsvm-functioanl-sswan/etc/neutron/.

For Neutron, how is the dsvm-functional job directing the rootwrap daemon
to use the files in the repo's .tox area?

Here is the review in quesstion:  https://review.openstack.org/#/c/168115/

Can anyone advise?

Thanks in advance!

Paul Michali (pc_m)
__
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] Please stop reviewing code while asking questions

[Zane Bitter]

On 24/04/15 07:21, Amrith Kumar wrote:

Julien,

We had a similar discussion within Trove several months ago and agreed to a 
convention that if you have a question, that should not warrant a -1 unless, as 
you indicate there's a strong reason to believe that the code is wrong and the 
question is leading.


+1. I'm kind of shocked that this even needed to be discussed, but well 
done :)



We discussed this at a mid-cycle and agreed to put our conventions in 
CONTRIBUTING.rst[1].

We had a hypothesis about why +0 was rarely used (never conclusively proved). 
Our hypothesis was that since Stackalytics didn't count +0's it led to an 
increased propensity to -1 something. It would be wonderful if we could try the 
experiment of giving credit for 0's and seeing if it changes behavior.


IIRC the problem here is the Gerrit API - it doesn't count +0 as a 
'review', so they just don't show up in any automated tools. (This isn't 
easily solved either, even assuming you're willing to modify Gerrit.)


There's nothing quite so antisocial as obstructing someone else's work 
to juice your own stats, and it's good to (gently) remind everyone of 
that occasionally.



It may be relevant to note that one of the recent candidates for TC also cited 
the possibility that a change in stackalytics was a causal factor in the change 
in behavior re: commits and reviews[2].

Maybe this is something that the new TC candidates can opine on; are these 
kinds of metrics driving bad behavior and if so what, if anything, can the TC 
do about it?


Individualised closed-loop metrics *always* drive bad behaviour, because 
they're necessarily only a sample of the behaviour we care about and to 
the extent that sample is representative of the whole, it can only 
remain so in the open-loop case. So we can, and should, tweak metrics to 
reduce bad behaviour and encourage good behaviour, but we shouldn't kid 
ourselves that we can eliminate unintended consequences - we can only 
exchange them for _different_ unintended consequences.


This is an open community, so we can't (and shouldn't want to) prevent 
people from publishing stats. The best case is that we use them only to 
inform us how we're doing in the aggregate, and discourage companies in 
particular from attaching individual incentives to game the metrics. 
Members of the TC, at least, (I don't know that there was ever an 
official edict or anything) have expressed this in the past, and I think 
it's one of those things that requires vigilance and periodic reminders.


cheers,
Zane.


-amrith

[1] https://github.com/openstack/trove/blob/master/CONTRIBUTING.rst
{2] http://openstack.markmail.org/thread/2xfapsmyy5i44adj

| -Original Message-
| From: Gorka Eguileor [mailto:gegui...@redhat.com]
| Sent: Friday, April 24, 2015 4:29 AM
| To: openstack-dev@lists.openstack.org
| Subject: Re: [openstack-dev] Please stop reviewing code while asking
| questions
|
| On Fri, Apr 24, 2015 at 10:14:38AM +0200, Julien Danjou wrote:
| > Hi there,
| >
| > This is now happening weekly to me now, probably because I write too
| > many patches touching almost all OpenStack projects once a cycle, and
| > I'm really tired of that behavior, so PLEASE:
| >
| >   *Stop sending Code-Review-1 when asking a question in a patch*
| >
| > _Sometimes_ there are good reasons to set -1 even when asking a
| > question. For example, when the question is a hint sent to the patch
| > author so that (s)he improves is commit message, a code comment or a
| > piece of code.
| >
| > But most of the time, if you ask a question because there's something
| > YOU DO NOT KNOW OR UNDERSTAND, do not put a score to a patchset. You
| > don't know the answer, so you have absolutely no right to evaluate a
| > patchset with -1. Just don't set a score, it's OK, and wait for the
| > answer before deciding if the patch is worth [-1..+2].
| >
| > Thank you for listening, and happy hacking!
| >
| > --
| > Julien Danjou
| > ;; Free Software hacker
| > ;; http://julien.danjou.info
|
| +1
|
| It does bother me too, especially when you answer the question and you
| never hear back from them and the -1 stays there...  XD
|
|
| Gorka
|
| __
| 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?

[Salvatore Orlando]

On 24 April 2015 at 15:13, Kyle Mestery  wrote:

> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe  wrote:
>
>> It's already away from the original thread, so I start this new one,
>> also with some extra tag because I think it touch some corss-project
>> area.
>>
>> Original discuss and reference:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062384.html
>>
>> https://review.openstack.org/#/c/176501/1/specs/liberty/reference-split.rst
>>
>> Background summary:
>> All in-tree implementation would be splitted from Openstack
>> networking, leaving Neutron as a naked "API/DB" platform, with a list
>> of out-tree implementation git repos, which are not maintained by core
>> team any more, but may be given a nominal "big tent" under the
>> Openstack umbrella.
>>
>>
> I'm not sure what led you to this discussion, but it's patently incorrect.
> We're going to split the in-tree reference implementation into a separate
> git repository. I have not said anything about the current core revewier
> team not being responsible for that. It's natural to evolve to a core
> reviewer team which cares deeply about that, vs. those who care deeply
> about the DB/API layer. This is exactly what happened when we split out the
> advanced services.
>

This discussion seems quite similar to that we had about non-reference
plugins.
Following the linux analogy you mention below Neutron should have been
deprived of its plugins and drivers. And indeed, regardless of what it
seems, it hasn't. Any user can still grab drivers as before. They just
reside in different repos. This is not different, imho, from the concept of
maintainers that linux has.
Besides you make it look at like as if the management layer (API/DB) is
just a tiny insignificant piece of software. I disagree quite strongly
here, but perhaps it's just me seeing in Neutron's mgmt layer something
more than what is actually is.


>
>
>> Motivation: a) Smaller core team only focus on the in-tree API/DB
>> definition, released from concrete controlling function
>> implementation; b) If there is official implementation inside Neutron,
>> 3rd external SDN controller would face the competition.
>>
>
Perhaps point (b) is a bit unclear. Are you stating that having this
control plane in Neutron gives it a "better placement" compared with other
solutions?


>
>> I'm not sure whether it's exactly what cloud operators want the
>> Openstack to deliver. Do they want a off-the-shelf package, or just a
>> framework and have to take the responsibility of integrating with
>> other external controlling projects? A analogy with Linux that only
>> kernel without any device driver has no use at all.
>>
>>
> We're still going to deliver ML2+OVS/LB+[DHCP, L3, metadata] agents for
> Liberty. I'm not sure where your incorrect assumption on what we're going
> to deliver is coming from.
>

I would answer with a different analogy - nova. Consider the various agents
as if it were libvirt. Like libvirt is a component which you use to control
your hypervisor, the agents control the data plane (OVS and utilities like
iptables/conntrack/dnsmasq/etc). With this analogy I believe Neutron's
"reference" control plane deserves to live on its own, just like nobody
would ever think that a libvirt implementation within nova is something
sane,
However, ML2 is a different beast. It has inside management and control
logic, we'll need a good surgeon there. Pretty sure our refactoring fans
are already drooling at the thought of cutting apart another component.


>
>
>> There are already many debates about nova-network to Neutron parity.
>> If largely used OVS and LB driver is out of tree and has to be
>> integrated separately by customers, how do those they migrate from
>> nova network? Standalone SDN controller has steep learning curve, and
>> a lot of users don't care which one is better of ODL vs. OpenContrail
>> to be integrated, they just want Openstack package easy to go by
>> default in tree implementation,  and are ready to drive all kinds of
>> opensource or commercial backends.
>>
>
I'm not sure what you mean here. In your opinions do operator want
something that works and provides everything out of the box, and want
something which is able to driver open source and commercial backends.
And besides I do not see the complication from operators arising from this
proposal. It's not like they have to maintain another component - indeed
from an operator perspective l3 agents, dhcp agents, and so on are already
different components to maintain (and that's one of the pain points they
feel in using neutron)

>
>>
> Do you realize that ML2 is plus the L2 agent is an SDN controller already?
>
>
>> BTW: +1 to henry and mathieu, that indeed Openstack is not responsible
>> projects of switch/router/fw, but it should be responsible for
>> scheduling, pooling, and driving of those backends, which is the same
>> case with Nova/Cinder scheduler and compute/volume manager. These
>> controlling functions shouldn't be 

Re: [openstack-dev] [all] Question for the TC candidates

[Zane Bitter]

On 24/04/15 09:00, Ed Leafe wrote:

I'm not sure what you see as the difference between the "end users" and the 
"operators" of OpenStack, because in my mind they are one and the same. I don't consider 
the people using, say, public cloud services to be OpenStack end users, because ultimately they 
just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our 
end users as the people who deploy and run OpenStack clouds.


Whoa! Back the terminology train up.

There's been longstanding confusion whenever anyone mentions the word 
"users" because it is ambiguous whether it refers to the people who 
deploy OpenStack clouds or the people who deploy workloads on them. This 
has largely been resolved by a conscious effort to refer to the two 
groups as "operators" and "end users" respectively.


The *last* thing we need is to muddy the waters again since, contrary to 
your (I hope inadvertent) implication, both groups are important and 
they often have different (and occasionally conflicting) interests. The 
qualifier "end" is there for a reason; don't ignore it.


cheers,
Zane.

__
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