Open Stack

Hi Experts,

I am following Havana guide for installation of three node set up.

After installing all services of NOVA ( nova-api , nova-cert, nova-scheduler, nova-consoleauth, nova-novncproxy ), when I tires to verify
All the things ....by # nova image-list  ( It gives 401 , unauthorized ).

>From nova-api log , I can there keystone.middleware.authtoken is rejecting request because of invalid authtoken.

Any pointer for the same.

Regards
Santosh



-----Original Message-----
From: openstack-dev-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org]
Sent: Thursday, November 14, 2013 12:33 PM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 19, Issue 33

Send OpenStack-dev mailing list submissions to
        openstack-dev at lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
        openstack-dev-request at lists.openstack.org

You can reach the person managing the list at
        openstack-dev-owner at lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."


Today's Topics:

   1. Re: Proposal to recognize indirect contributions to our code
      base (Colin McNamara)
   2. Re: [qa] Tracking development of scenario tests (Christopher Yeoh)
   3. [style] () vs \ continuations (Robert Collins)
   4. Re: [style] () vs \ continuations (Dan Smith)
   5. Re: [style] () vs \ continuations (Sean Dague)
   6. Re: [style] () vs \ continuations (Robert Collins)
   7. Re: Glance Tasks (Jay Pipes)
   8. Re: [Nova] Request for review ( PCI passthrough API)
      (Tian, Shuangtai)
   9. Re: Proposal to recognize indirect contributions to our code
      base (Stefano Maffulli)
  10. Re: Problems with glance when using token v3 (haruka tanizawa)
  11. Re: Proposal to recognize indirect contributions to our code
      base (Robert Collins)
  12. [Neturon][Tempest] A test scenario for services (Nachi Ueno)
  13. Re: [Neturon][Tempest] A test scenario for services
      (Salvatore Orlando)
  14. Re: [Neturon][Tempest] A test scenario for services
      (Sumit Naiksatam)
  15. Re: [style] () vs \ continuations (Chris Behrens)
  16. Re: [qa] Tracking development of scenario tests (David Kranz)
  17. [Nova] Help to approve the pci-api-support blueprint
      (Tian, Shuangtai)
  18. Re: [style] () vs \ continuations (Robert Collins)
  19. Re: [PTL] Proposed Icehouse release schedule (Jeremy Stanley)
  20. Re: [Neutron] New plug-ins requirements (Salvatore Orlando)
  21.  Gate Math or why you you keep typing 'recheck' (Joe Gordon)
  22. Using custom IPAM with OpenStack (Lari Partanen)
  23. Re: [ALL] Removing generate_uuid() from uuidutils (Clint Byrum)
  24. Re: Gate Math or why you you keep typing 'recheck'
      (Robert Collins)
  25. Re: [Solum] Command Line Interface for Solum (Noorul Islam K M)
  26. Re: Using custom IPAM with OpenStack (Sumit Naiksatam)
  27. Re: [Neturon][Tempest] A test scenario for services (Nachi Ueno)
  28. Re: [qa] Tracking development of scenario tests (Masayuki Igawa)
  29. libvirt_type Doc Bug (Lana Brindley)
  30. Re: libvirt_type Doc Bug (Sankarshan Mukhopadhyay)
  31. Re: [openstack-qa] [qa][nova] The document for the changes
      from Nova v2 api to v3 (Alex Xu)
  32. Re: [Neturon][Tempest] A test scenario for services
      (Eugene Nikanorov)
  33. Re: [openstack-qa] [qa][nova] The document for the changes
      from Nova v2 api to v3 (Alex Xu)
  34. Re: [qa] Tracking development of scenario tests (Giulio Fidente)
  35. Re: [Neturon][Tempest] A test scenario for services (Nachi Ueno)
  36. Re: [ALL] Removing generate_uuid() from uuidutils (Joshua Harlow)
  37. Re: [Neutron] Blueprint -- Floating IP Auto       Association
      (Jaume Devesa)
  38. Re: Using custom IPAM with OpenStack (Lari Partanen)
  39. Re: [Neutron] Blueprint -- Floating IP    Auto    Association
      (Steven Weston)
  40. Re: libvirt_type Doc Bug (Michael Still)
  41. Re: [Nova] [Ironic] [TripleO] scheduling flow     with    Ironic?
      (Alex Glikson)
  42. Re: [Heat]Updated summit etherpad: API-retry-with-idempotency
      (Mitsuru Kanabuchi)
  43. Re: [style] () vs \ continuations (Chris Behrens)
  44. Re: libvirt_type Doc Bug (Robert Collins)
  45. Re: RFC: reverse the default Gerrit sort order (Mike Perez)
  46. Re: [style] () vs \ continuations (Robert Collins)
  47. Re: [style] () vs \ continuations (Zhongyue Luo)
  48. Re: [Neutron] New plug-ins requirements (Edgar Magana)


----------------------------------------------------------------------

Message: 1
Date: Thu, 14 Nov 2013 08:34:22 +0800
From: Colin McNamara <colin at 2cups.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Proposal to recognize indirect
        contributions to our code base
Message-ID:
        <CAM-CME_9QxBKs-K0=K2+1tub3ArDWrho+z=wHLZ3X+XktbNtVw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Not to be contrarian, but 92% of the commits in Havana came from
non-individual contributions. The majority of those came from big name
companies (IBM, RedHat, etc).

What I see as a great thing is the increasing number [and diversity] of
companies committing, especially from end user/operators.

In the operator case, there are examples where an operator uses another
companies Dev's to write a patch for their install that gets commited
upstream. In this case, the patch was sponsored by the operator company,
written and submitted by a developer employed by another.

Allowing for tracking if the fact that an operator/end user sponsored a
patch to be created further incents more operators/end users to put funds
towards getting features written.

This is a positive for the project, it's Dev's and the community. It also
opens up an expanded market for contract developers working on specifier
features.

My perspective - I work at and operator / integrator. I have my teams
working on multiple projects including OpenStack. Peers of mine in Silicon
Valley who have funded major OpenStaxk development Efforts have required
that code to be released, but have had trouble verifying. The sponsored by
tag would provide an easy way of tracking, as well as further incent the
behavior of funding improvements.

My 2 cents.

On Thursday, November 14, 2013, Jay Pipes wrote:

> On 11/11/2013 12:44 PM, Daniel P. Berrange wrote:
>
>> On Mon, Nov 11, 2013 at 03:20:20PM +0100, Nicolas Barcet wrote:
>>
>>> Dear TC members,
>>>
>>> Our companies are actively encouraging our respective customers to have
>>> the
>>> patches they mission us to make be contributed back upstream.  In order
>>> to
>>> encourage this behavior from them and others, it would be nice that if
>>> could gain some visibility as "sponsors" of the patches in the same way
>>> we
>>> get visibility as "authors" of the patches today.
>>>
>>> The goal here is not to provide yet another way to count affiliations of
>>> direct contributors, nor is it a way to introduce sales pitches in
>>> contrib.
>>>   The only acceptable and appropriate use of the proposal we are making
>>> is
>>> to signal when a patch made by a contributor for another comany than the
>>> one he is currently employed by.
>>>
>>> For example if I work for a company A and write a patch as part of an
>>> engagement with company B, I would signal that Company B is the sponsor
>>> of
>>> my patch this way, not Company A.  Company B would under current
>>> circumstances not get any credit for their indirect contribution to our
>>> code base, while I think it is our intent to encourage them to
>>> contribute,
>>> even indirectly.
>>>
>>> To enable this, we are proposing that the commit text of a patch may
>>> include a
>>>     sponsored-by: <sponsorname>
>>> line which could be used by various tools to report on these commits.
>>>   Sponsored-by should not be used to report on the name of the company
>>> the
>>> contributor is already affiliated to.
>>>
>>> We would appreciate to see your comments on the subject and eventually
>>> get
>>> your approval for it's use.
>>>
>>
>> IMHO, lets call this what it is: "marketing".
>>
>> I'm fine with the idea of a company wanting to have recognition for work
>> that they fund. They can achieve this by putting out a press release or
>> writing a blog post saying that they "funded awesome feature XYZ to bring
>> benefits ABC to the project" on their own websites, or any number of other
>> marketing approaches. Most / many companies and individuals contributing
>> to OpenStack in fact already do this very frequently which is fine /
>> great.
>>
>> I don't think we need to, nor should we, add anything to our code commits,
>> review / development workflow / toolchain to support such marketing
>> pitches.
>> The identities recorded in git commits / gerrit reviewes / blueprints etc
>> should exclusively focus on technical authorship, not sponsorship. Leave
>> the marketing pitches for elsewhere.
>>
>
> I agree with Daniel here. There's nothing wrong with marketing, and
> there's nothing wrong with a company promoting the funding that it
> contributed to get some feature written or high profile bug fixed. But, I
> don't believe this marketing belongs in the commit log. In the open source
> community, *individuals* develop and contribute code, not companies. And
> I'm not talking about joint contribution agreements, like the corporate
> CLA. I'm talking about the actual work that is performed by developers,
> technical documentation folks, QA folks, etc. Source control should be the
> domain of the individual, not the company.
>
> Best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/6020bbf9/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 14 Nov 2013 11:05:50 +1030
From: Christopher Yeoh <cbkyeoh at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [qa] Tracking development of scenario
        tests
Message-ID:
        <CANCY3edE3L9kZgNNRwv3GdFFDZ6ABepgy8-XjJPr23-hPTr0sw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Nov 14, 2013 at 9:54 AM, David Kranz <dkranz at redhat.com> wrote:

> It was clear at the summit that there is a pressing need for more scenario
> tests. A number of folks have volunteered to participate so we need a way
> to track progress and avoid duplication. We have not had great satisfaction
> using either bugs or blueprints, so Sean and I are proposing a more
> "self-service" approach and process:
>
> 1. Developer checks in the zeroth version of a scenario test as work in
> progress. It contains a description of the test, and     possibly work
> items.  This will "claim" the area of the proposed scenario to avoid
> duplication and allow others to comment through gerrit.
>

I don't know how well it maps for scenario testing, but I think the
spreadsheet approach for the API tests has worked pretty well. Makes the
breakdown of large chunks of work more manageable

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/2a874aad/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 14 Nov 2013 13:46:35 +1300
From: Robert Collins <robertc at robertcollins.net>
To: OpenStack Development Mailing List
        <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [style] () vs \ continuations
Message-ID:
        <CAJ3HoZ2obZi-CW3+c7Z-Nu6YBP4SLe3wy3PvQvVmU_y2t+oiSg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi so - in http://docs.openstack.org/developer/hacking/

it has as bullet point 4:
Long lines should be wrapped in parentheses in preference to using a
backslash for line continuation.

I'm seeing in some reviews a request for () over \ even when \ is
significantly clearer.

I'd like us to avoid meaningless reviewer churn here: can we either:
 - go with PEP8 which also prefers () but allows \ when it is better
   - and reviewers need to exercise judgement when asking for one or other
 - make it a hard requirement that flake8 detects

My strong recommendation is to go with PEP8 and exercising of judgement.

The case that made me raise this is this:
    folder_exists, file_exists, file_size_in_kb, disk_extents = \
        self._path_file_exists(ds_browser, folder_path, file_name)

Wrapping that in brackets gets this;
    folder_exists, file_exists, file_size_in_kb, disk_extents = (
        self._path_file_exists(ds_browser, folder_path, file_name))

Which is IMO harder to read - double brackets, but no function call,
and no tuple: it's more ambiguous than \.

from https://review.openstack.org/#/c/48544/15/nova/virt/vmwareapi/vmops.py

Cheers,
Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 4
Date: Wed, 13 Nov 2013 16:59:14 -0800
From: Dan Smith <dms at danplanet.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID: <52842062.5010802 at danplanet.com>
Content-Type: text/plain; charset=ISO-8859-1

> I'd like us to avoid meaningless reviewer churn here:

I'd like us to avoid trivial style guideline churn :)

> The case that made me raise this is this:
>     folder_exists, file_exists, file_size_in_kb, disk_extents = \
>         self._path_file_exists(ds_browser, folder_path, file_name)
>
> Wrapping that in brackets gets this;
>     folder_exists, file_exists, file_size_in_kb, disk_extents = (
>         self._path_file_exists(ds_browser, folder_path, file_name))
>
> Which is IMO harder to read - double brackets, but no function call,
> and no tuple: it's more ambiguous than \.

I prefer consistency for readability over most everything. In Nova, we
have a few cases of backslash continuations, which I think are mostly in
old db_api code, but I think it's overwhelmingly paren-based
continuations. I'd much rather keep things the way they are except for
situations where there is a real problem. I think that when modifying
existing backslash-using code, nobody argues, and I think that if an
author were to make a reasonable readability argument in a specific
case, that reviewers would allow the backslash method.

--Dan




------------------------------

Message: 5
Date: Wed, 13 Nov 2013 19:59:51 -0500
From: Sean Dague <sean at dague.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID: <52842087.7050600 at dague.net>
Content-Type: text/plain; charset="iso-8859-1"

On 11/13/2013 07:46 PM, Robert Collins wrote:
> Hi so - in http://docs.openstack.org/developer/hacking/
>
> it has as bullet point 4:
> Long lines should be wrapped in parentheses in preference to using a
> backslash for line continuation.
>
> I'm seeing in some reviews a request for () over \ even when \ is
> significantly clearer.
>
> I'd like us to avoid meaningless reviewer churn here: can we either:
>  - go with PEP8 which also prefers () but allows \ when it is better
>    - and reviewers need to exercise judgement when asking for one or other
>  - make it a hard requirement that flake8 detects
>
> My strong recommendation is to go with PEP8 and exercising of judgement.
>
> The case that made me raise this is this:
>     folder_exists, file_exists, file_size_in_kb, disk_extents = \
>         self._path_file_exists(ds_browser, folder_path, file_name)
>
> Wrapping that in brackets gets this;
>     folder_exists, file_exists, file_size_in_kb, disk_extents = (
>         self._path_file_exists(ds_browser, folder_path, file_name))
>
> Which is IMO harder to read - double brackets, but no function call,
> and no tuple: it's more ambiguous than \.
>
> from https://review.openstack.org/#/c/48544/15/nova/virt/vmwareapi/vmops.py

This is an area where we actually have consensus in our docs (have had
for a while), the reviewer was being consistent with them, and it feels
like you are reopening that for personal preference.

Honestly I find \ at the end of a line ugly as sin, and completely
jarring to read. I actually do like the second one better. I don't care
enough to change a policy on it, but we do already have a policy, so it
seems pretty pedantic, and not useful.

Bringing up for debate the style guide every time it disagrees with your
personal preference isn't a very effective use of people's time.
Especially on settled matters.

        -Sean

--
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/e654ef02/attachment-0001.pgp>

------------------------------

Message: 6
Date: Thu, 14 Nov 2013 14:08:05 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID:
        <CAJ3HoZ20eOFdDMyYdmDCWR-_JY22Qov2mH7oU5NMzT-cFm1F2g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 14 November 2013 13:59, Sean Dague <sean at dague.net> wrote:

> This is an area where we actually have consensus in our docs (have had
> for a while), the reviewer was being consistent with them, and it feels
> like you are reopening that for personal preference.

Sorry that it feels that way. My personal code also uses ()
overwhelmingly - so this isn't a personal agenda issue. I brought it
up because the person that wrote the code had chosen to use \, and as
far as I knew we didn't have a hard decision either way - and the
style guide we have talks preference not requirement, but the review
didn't distinguish between whether it's a suggestion or a requirement.
I'm seeking clarity so I can review more effectively and so that our
code doesn't end up consistent but hard to read.

> Honestly I find \ at the end of a line ugly as sin, and completely
> jarring to read. I actually do like the second one better. I don't care
> enough to change a policy on it, but we do already have a policy, so it
> seems pretty pedantic, and not useful.

Ok, thats interesting. Readability matters, and if most folk find that
even this case - which is pretty much the one case where I would argue
for \ - is still easier to read with (), then thats cool.

> Bringing up for debate the style guide every time it disagrees with your
> personal preference isn't a very effective use of people's time.
> Especially on settled matters.

Totally not what I'm doing. I've been told that much of our style
guide was copied lock stock and barrel from some Google Python style
guide, so I can't tell what is consensus and what is 'what someone
copied down one day'. Particularly when there is no rationale included
against the point - its a black box and entirely opaque.

-Rob

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 7
Date: Wed, 13 Nov 2013 20:08:04 -0500
From: Jay Pipes <jaypipes at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Glance Tasks
Message-ID: <52842274.6020101 at gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Sorry for top-posting, but in summary, I entirely agree with George
here. His logic is virtually identical to the concerns I raised with the
initial proposal for Glance Tasks here:

http://lists.openstack.org/pipermail/openstack-dev/2013-May/009400.html
and
http://lists.openstack.org/pipermail/openstack-dev/2013-May/009527.html

Best,
-jay

On 11/13/2013 05:36 PM, George Reese wrote:
> Let?s preface this with Glance being the part of OpenStack I am least
> familiar with. Keep in mind my commentary is related to the idea that
> the asynchronous tasks as designed are being considered beyond Glance.
> The problems of image upload/import/cloning/export are unlike other
> OpenStack operations for the most part in that they involve binary data
> as the core piece of the payload.
>
> Having said that, I?d prefer a polymorphic POST to the tasks API as
> designed. But I?m much more concerned with the application of the tasks
> API as designed to wider problems.
>
> Basically, I?d stick with POST /images.
>
> The content type should indicate what the server should expect.
> Basically, the content can be:
>
> * An actual image to upload
> * Content describing a target for an import
> * Content describing a target for a clone operation
>
> Implementation needs dictate whether any given operation is synchronous
> or asynchronous. Practically speaking, upload would be synchronous with
> the other two being asynchronous. This would NOT impact an existing
> /images POST as it will not change (unless we suddenly made it
> asynchronous).
>
> The response would be CREATED (synchronous) or ACCEPTED (asynchronous).
> If ACCEPTED, the body would contain JSON/XML describing the asynchronous
> task.
>
> I?m not sure if export is supposed to export to a target object store or
> export to another OpenStack environment. But it would be an async
> operation either way and should work as described above. Whether the
> endpoint for the image to be exported is the target or just /images is
> something worthy of discussion based on what the actual function of the
> export is.
>
> -George
>
> On Nov 12, 2013, at 5:45 PM, John Bresnahan <john at bresnahan.me
> <mailto:john at bresnahan.me>> wrote:
>
>> George,
>>
>> Thanks for the comments, they make a lot of sense.  There is a Glance
>> team meeting on Thursday where we would like to push a bit further on
>> this.  Would you mind sending in a few more details? Perhaps a sample
>> of what your ideal layout would be?  As an example, how would you
>> prefer actions are handled that do not effect a currently existing
>> resource but ultimately create a new resource (for example the import
>> action).
>>
>> Thanks!
>>
>> John
>>
>>
>> On 11/11/13, 8:05 PM, George Reese wrote:
>>> I was asked at the OpenStack Summit to look at the Glance Tasks,
>>> particularly as a general pattern for other asynchronous operations.
>>>
>>> If I understand Glance Tasks appropriately, different asynchronous
>>> operations get replaced by a single general purpose API call?
>>>
>>> In general, a unified API for task tracking across all kinds of
>>> asynchronous operations is a good thing. However, assuming this
>>> understanding is correct, I have two comments:
>>>
>>> #1 A consumer of an API should not need to know a priori whether a
>>> given operation is ?asynchronous?. The asynchronous nature of the
>>> operation should be determined through a response. Specifically, if
>>> the client gets a 202 response, then it should recognize that the
>>> action is asynchronous and expect a task in the response. If it gets
>>> something else, then the action is synchronous. This approach has the
>>> virtual of being proper HTTP and allowing the needs of the
>>> implementation to dictate the synchronous/asynchronous nature of the
>>> API call and not a fixed contract.
>>>
>>> #2 I really don?t like the idea of a single endpoint (/v2/tasks) for
>>> executing all tasks for a particular OpenStack component. Changes
>>> should be made through the resource being impacted.
>>>
>>> -George
>>>
>>> --
>>> George Reese (george.reese at imaginary.com
>>> <mailto:george.reese at imaginary.com>)
>>> t: @GeorgeReese               m: +1(207)956-0217
>>> <tel:%2B1%28207%29956-0217>               Skype: nspollution
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> George Reese (george.reese at imaginary.com
> <mailto:george.reese at imaginary.com>)
> t: @GeorgeReese               m: +1(207)956-0217
> <tel:%2B1%28207%29956-0217>               Skype: nspollution
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




------------------------------

Message: 8
Date: Thu, 14 Nov 2013 01:13:03 +0000
From: "Tian, Shuangtai" <shuangtai.tian at intel.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Request for review ( PCI
        passthrough API)
Message-ID:
        <D257A88891CE804980A98277363059F6013C143B at SHSMSX103.ccr.corp.intel.com>

Content-Type: text/plain; charset="us-ascii"

Hi Chris,
I rebased the patches again. And added realistic data to tests.
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:pci-api-support,n,z
Thanks!

From: Christopher Yeoh [mailto:cbkyeoh at gmail.com]
Sent: Monday, November 11, 2013 4:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Request for review ( PCI passthrough API)

Hi Tian,
A couple of things that came out of the V3 API discussions which are relevant to your patches:
- In Icehouse we want to merge the V3 API version of patches either before the V2 one or in the same patch. With
  yours split its probably easiest to do that by setting the V2 patches dependent on the V3 ones.
- I've added this previously in the review comments for some of the patches that we also would
  like a specification written up for the REST API which you are adding (not just what data is returned,
  but the methods (GET/POST/PUT/DELETE), URLs, data format in and data format out).

  At this point in time in the blueprint is probably best approach with a summary in the commit message
  for the portion which is added (since the API changes are split up - which is good)
Regards,

Chris


On Mon, Nov 11, 2013 at 7:23 PM, Tian, Shuangtai <shuangtai.tian at intel.com<mailto:shuangtai.tian at intel.com>> wrote:
Hi,All

PCI pass-through support has been added to nova. Now we are doing the apis to support PCI pass-through.
Pls review the code :https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:pci-api-support,n,z

Thank you very much.

Best regards,
Tian, Shuangtai


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/215f85b3/attachment-0001.html>

------------------------------

Message: 9
Date: Wed, 13 Nov 2013 17:20:46 -0800
From: Stefano Maffulli <stefano at openstack.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Proposal to recognize indirect
        contributions to our code base
Message-ID: <5284256E.2 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1

On 11/13/2013 04:34 PM, Colin McNamara wrote:
> Not to be contrarian, but 92% of the commits in Havana came from
> non-individual contributions. The majority of those came from big name
> companies (IBM, RedHat, etc).

ow, that's harsh. Despite what US Supreme Court Judges may think,
Companies are not people: in the contest of this discussion (and for the
purpose of reporting on development activity) companies don't *do*
anything besides pay salaries of people. Red Hat, IBM, Rackspace, HP,
etc happen to pay the salaries of hundreds of skilled developers. That's
it. I happen to have started reporting publicly on companies activity
because I (as community manager) need to understand the full extent of
the dynamics inside the ecosystem. Those numbers are public and some
pundits abuse of them to fuel PR flaming machines.

> In the operator case, there are examples where an operator uses another
> companies Dev's to write a patch for their install that gets commited
> upstream. In this case, the patch was sponsored by the operator company,
> written and submitted by a developer employed by another.
>
> Allowing for tracking if the fact that an operator/end user sponsored a
> patch to be created further incents more operators/end users to put
> funds towards getting features written.

I am not convinced at all that such thing would be of any incentive for
operators to contribute upstream. The practical advantage of having a
feature upstream maintained by somebody else should be more than enough
to justify it. I see the PR/marketing value in it, not a practical one.
On the other hand, I see potential for incentive to damaging behaviour.

As others have mentioned already, we have a lot of small contributions
coming in the code base but we're generally lacking people involved in
the hard parts of OpenStack. We need people contributing to 'thankless'
jobs that need to be done: from code reviewers to QA people to the
Security team, we need people involved there. I fear that giving
incentives to such small "vanity contributions" would do harm to our
community.

> This is a positive for the project, it's Dev's and the community. It
> also opens up an expanded market for contract developers working on
> specifier features.

I also don't see any obstacle for any company to proudly issue a press
release, blog post or similar, saying that they have sponsored a
feature/bug fix in OpenStack giving credit to developers/company writing
it. Why wouldn't that be enough? Why do we need to put in place a
reporting machine for what seems to be purely a marketing/pr need?

> My perspective - I work at and operator / integrator. I have my teams
> working on multiple projects including OpenStack. Peers of mine in
> Silicon Valley who have funded major OpenStaxk development Efforts have
> required that code to be released, but have had trouble verifying. The
> sponsored by tag would provide an easy way of tracking, as well as
> further incent the behavior of funding improvements.

I think you're raising a different problem here: can you specify better
what your (peers) sponsors have trouble verifying?

/stef



------------------------------

Message: 10
Date: Thu, 14 Nov 2013 10:27:40 +0900
From: haruka tanizawa <harubelle at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Problems with glance when using token v3
Message-ID:
        <CAG=R24DMgYDkCWbnSRq8wU1-PwMzW2EsaCktzK70miJWhwK6iA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Maybe same issue?

https://bugs.launchpad.net/neutron/+bug/1251026
https://bugs.launchpad.net/keystone/+bug/1186177

Haruka Tanizawa


2013/11/14 Telles Nobrega <tellesnobrega at gmail.com>

> Hi, I'm trying to start an instance using a token v3 but I'm getting this
> error
> http://paste.openstack.org/show/52504/
> Anyone has experienced this before or have any ideas how to solve it?
>
> --
> ------------------------------------------
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/b5c62b2c/attachment-0001.html>

------------------------------

Message: 11
Date: Thu, 14 Nov 2013 14:29:17 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Proposal to recognize indirect
        contributions to our code base
Message-ID:
        <CAJ3HoZ24ETxpjKKEtGRqcj3FMdiHzMSmS5qa5WukFyz2yw6Fng at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 14 November 2013 13:34, Colin McNamara <colin at 2cups.com> wrote:
> Not to be contrarian, but 92% of the commits in Havana came from
> non-individual contributions. The majority of those came from big name
> companies (IBM, RedHat, etc).
>
> What I see as a great thing is the increasing number [and diversity] of
> companies committing, especially from end user/operators.
>
> In the operator case, there are examples where an operator uses another
> companies Dev's to write a patch for their install that gets commited
> upstream. In this case, the patch was sponsored by the operator company,
> written and submitted by a developer employed by another.
>
> Allowing for tracking if the fact that an operator/end user sponsored a
> patch to be created further incents more operators/end users to put funds
> towards getting features written.
>
> This is a positive for the project, it's Dev's and the community. It also
> opens up an expanded market for contract developers working on specifier
> features.
>
> My perspective - I work at and operator / integrator. I have my teams
> working on multiple projects including OpenStack. Peers of mine in Silicon
> Valley who have funded major OpenStaxk development Efforts have required
> that code to be released, but have had trouble verifying. The sponsored by
> tag would provide an easy way of tracking, as well as further incent the
> behavior of funding improvements.
>
> My 2 cents.

It's not *at all* clear that the publicity from having commits tagged
as 'sponsored by FOO' are valuable for organisation Foo. There are two
scenarios I can see where this turns up:

a) Operator/Deployer X wants a bugfix/feature and their supporting
organisation Y delivers the work for them.
b) Vendor X wants a bugfix/feature and they contract to another
OpenStack connected organisation Y to do the work for them.

For case a) the reward of getting the work done is it's own benefit.
There is perhaps a tiny bit of kudos they get by upstreaming the code,
but as being a contributor to OpenStack isn't key to their business
model, it's marginal at best: if being a contributor was key, they
would be resourcing the work themselves.

For case b) again the feature/bugfix is it's own benefit - the vendors
users get the ability to use the bugfix/feature and the vendor can
sell more of their product. And again, if being part of the OpenStack
community is core to their plans, they will be doing that!

So - there are intrinsic motivators for doing this work. Do we need to
track the (I suspect) small fraction of patches with this provenance
in an explicit fashion at all?

-Rob

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 12
Date: Thu, 14 Nov 2013 10:55:57 +0900
From: Nachi Ueno <nachi at ntti3.com>
To: OpenStack Development Mailing List
        <openstack-dev at lists.openstack.org>,  Sumit Naiksatam
        <sumit.naiksatam at bigswitch.com>, Eugene Nikanorov
        <enikanorov at mirantis.com>
Subject: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CABJepwhBCodM4NB2Xqoxik+65Yq0mUK8-9vgmb9o8hdcUaaO1A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Sumit, Eugene

How about to have one test scenario for services?
IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
because of utilization of test resources.

I wrote my proposal here.
https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016

I'm thinking about to use Heat for this testing, because we can re-use
the heat template.

Best
Nachi



------------------------------

Message: 13
Date: Thu, 14 Nov 2013 02:21:06 +0000
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Cc: Sumit Naiksatam <sumit.naiksatam at bigswitch.com>
Subject: Re: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CAGR=i3iQwSjaxRmKNz2Tz=SUixuPwLt5LYCcTe6gMoXtot3rFg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks Nachi.

I dared to leave some unsolicited comments on the document you shared.

Salvatore


On 14 November 2013 01:55, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Sumit, Eugene
>
> How about to have one test scenario for services?
> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
> because of utilization of test resources.
>
> I wrote my proposal here.
>
> https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016
>
> I'm thinking about to use Heat for this testing, because we can re-use
> the heat template.
>
> Best
> Nachi
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/bb11b585/attachment-0001.html>

------------------------------

Message: 14
Date: Wed, 13 Nov 2013 18:26:35 -0800
From: Sumit Naiksatam <sumitnaiksatam at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Cc: Sumit Naiksatam <sumit.naiksatam at bigswitch.com>
Subject: Re: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CAMWrLvjtEAS012mYXGoaj0SF1Kt=xazUma4Ypkchmw--uaE-Jw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks Nachi. So is the suggestion to not have tempest tests (testing API)
for each individual service?

~Sumit.


On Wed, Nov 13, 2013 at 5:55 PM, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Sumit, Eugene
>
> How about to have one test scenario for services?
> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
> because of utilization of test resources.
>
> I wrote my proposal here.
>
> https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016
>
> I'm thinking about to use Heat for this testing, because we can re-use
> the heat template.
>
> Best
> Nachi
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/3456f060/attachment-0001.html>

------------------------------

Message: 15
Date: Wed, 13 Nov 2013 18:28:03 -0800
From: Chris Behrens <cbehrens at codestud.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Cc: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID: <04E8A3D3-4E1E-4954-BC54-F9E9CA097E0D at codestud.com>
Content-Type: text/plain;       charset=us-ascii

For this example, I'd look at using parens on the left side to see if that helps.  I also, like Sean, really dislike the look of \.

> On Nov 13, 2013, at 5:08 PM, Robert Collins <robertc at robertcollins.net> wrote:
>
>> On 14 November 2013 13:59, Sean Dague <sean at dague.net> wrote:
>>
>> This is an area where we actually have consensus in our docs (have had
>> for a while), the reviewer was being consistent with them, and it feels
>> like you are reopening that for personal preference.
>
> Sorry that it feels that way. My personal code also uses ()
> overwhelmingly - so this isn't a personal agenda issue. I brought it
> up because the person that wrote the code had chosen to use \, and as
> far as I knew we didn't have a hard decision either way - and the
> style guide we have talks preference not requirement, but the review
> didn't distinguish between whether it's a suggestion or a requirement.
> I'm seeking clarity so I can review more effectively and so that our
> code doesn't end up consistent but hard to read.
>
>> Honestly I find \ at the end of a line ugly as sin, and completely
>> jarring to read. I actually do like the second one better. I don't care
>> enough to change a policy on it, but we do already have a policy, so it
>> seems pretty pedantic, and not useful.
>
> Ok, thats interesting. Readability matters, and if most folk find that
> even this case - which is pretty much the one case where I would argue
> for \ - is still easier to read with (), then thats cool.
>
>> Bringing up for debate the style guide every time it disagrees with your
>> personal preference isn't a very effective use of people's time.
>> Especially on settled matters.
>
> Totally not what I'm doing. I've been told that much of our style
> guide was copied lock stock and barrel from some Google Python style
> guide, so I can't tell what is consensus and what is 'what someone
> copied down one day'. Particularly when there is no rationale included
> against the point - its a black box and entirely opaque.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



------------------------------

Message: 16
Date: Wed, 13 Nov 2013 21:31:23 -0500
From: David Kranz <dkranz at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [qa] Tracking development of scenario
        tests
Message-ID: <528435FB.1000206 at redhat.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 11/13/2013 07:35 PM, Christopher Yeoh wrote:
> On Thu, Nov 14, 2013 at 9:54 AM, David Kranz <dkranz at redhat.com
> <mailto:dkranz at redhat.com>> wrote:
>
>     It was clear at the summit that there is a pressing need for more
>     scenario tests. A number of folks have volunteered to participate
>     so we need a way to track progress and avoid duplication. We have
>     not had great satisfaction using either bugs or blueprints, so
>     Sean and I are proposing a more "self-service" approach and process:
>
>     1. Developer checks in the zeroth version of a scenario test as
>     work in progress. It contains a description of the test, and
>     possibly work items.  This will "claim" the area of the proposed
>     scenario to avoid duplication and allow others to comment through
>     gerrit.
>
>
> I don't know how well it maps for scenario testing, but I think the
> spreadsheet approach for the API tests has worked pretty well. Makes
> the breakdown of large chunks of work more manageable
>
> Chris
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yeah, I thought about that. It works well when the spec is a collection
of independent one-liners like it is for apis but scenarios are more
involved. I also like the idea of putting the spec together with the
code and the commenting utility of gerrit. We thought it was worth a try.

  -David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/cc391350/attachment-0001.html>

------------------------------

Message: 17
Date: Thu, 14 Nov 2013 02:36:35 +0000
From: "Tian, Shuangtai" <shuangtai.tian at intel.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Nova] Help to approve the pci-api-support
        blueprint
Message-ID:
        <D257A88891CE804980A98277363059F6013C14D8 at SHSMSX103.ccr.corp.intel.com>

Content-Type: text/plain; charset="us-ascii"

Hi All

Can someone help to approve the pci-api-support bp https://blueprints.launchpad.net/nova/+spec/pci-api-support?
That will need to be done before we start merging code, and the patches are ready.
Thanks for help!

Best regards,
Tian, Shuangtai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/873aebeb/attachment-0001.html>

------------------------------

Message: 18
Date: Thu, 14 Nov 2013 15:55:36 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID:
        <CAJ3HoZ2qNV2pu4ZrbRD=9ykyNgL9RRGwvRW0d5QTQHH=qW0pjw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 14 November 2013 15:28, Chris Behrens <cbehrens at codestud.com> wrote:
> For this example, I'd look at using parens on the left side to see if that helps.  I also, like Sean, really dislike the look of \.

I dislike \ most of the time too :).


>>> (foo, bar, baz =
  File "<stdin>", line 1
    (foo, bar, baz =
                   ^
SyntaxError: invalid syntax

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 19
Date: Thu, 14 Nov 2013 03:07:04 +0000
From: Jeremy Stanley <fungi at yuggoth.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [PTL] Proposed Icehouse release schedule
Message-ID: <20131114030703.GP2304 at yuggoth.org>
Content-Type: text/plain; charset=us-ascii

On 2013-11-13 14:15:31 +0100 (+0100), Thierry Carrez wrote:
[...]
> * Week of April 21
[...]

I've already got travel plans this week, so works for me (and
release week too, though it was scheduled well over a year ago).

> * Week of April 28
[...]

I'll be back this week and catching up on things, so I'm happy to be
the lonely soul keeping the lights on in Infra if needed.
--
Jeremy Stanley



------------------------------

Message: 20
Date: Thu, 14 Nov 2013 03:11:47 +0000
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] New plug-ins requirements
Message-ID:
        <CAGR=i3gZF0uQBaHHh_qLNWwG+XTYyUZ726KeB-ftqnTuD-VqAA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I reckon we should wait a little for the PTL to propose a draft of the
policy we can comment on.

'thirdy paty test' probably was meant as integration with gerrit (
http://ci.openstack.org/third_party.html); the test suite to be executed
is, obviously, the tempest test suite.
In my opinion, the policy will define criteria for acceptability of skipped
tests and ability of adding plugin-specific tests.

Regards,
Salvatore


On 12 November 2013 15:15, Kyle Mestery (kmestery) <kmestery at cisco.com>wrote:

> On Nov 12, 2013, at 2:46 AM, Robert Collins <robertc at robertcollins.net>
> wrote:
> > On 12 November 2013 21:15, Edgar Magana <emagana at plumgrid.com> wrote:
> >> Team,
> >>
> >> It has been decided during the Icehouse summit that all vendor specific
> >> plug-ins should enforce remote tempest tests:
> >> http://ci.openstack.org/third_party.html
> >>
> >> I would like to understand if we will apply this rule for any new
> plug-in
> >> during Icehouse or we will start applying this new requirement until "J"
> >> timeframe.
> >
> > I can't comment on when - thats a Neutron dev decision, but I heartily
> > endorse getting all code paths tested asap :).
> >
> My personal opinion is if we are going to require all existing Neutron
> plugins to
> have valid smokestack tests by Icehouse-2, then any new plugins should not
> be allowed into the tree without those tests. This includes new Modular
> Layer 2
> MechanismDrivers as well.
>
> >> I do believe that should enforce this new requirement ASAP but I also
> >> believe that we need to provide a little bit more of guidance on this
> >> process.
> >> So, Besides the above mentioned wiki, is there any more information
> that we
> >> can provide about this new requirement? I think we should update Neutron
> >> wiki with this information.
> >> If somebody is very familiar with the process will be interested in
> posting
> >> their input on this thread.
> >
> > I think the requirement of 'use third party tests' is confusing goal
> > with implementation: the goal should be that 'all vendor plugins be CI
> > tested at verification level at minimum'. This leaves room for gate
> > based testing of such plugins too, if the vendor steps up and meets
> > the requirements to have their plugin be gate checked - which is
> > superior to merely doing verification checks.
> >
> > -Rob
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/1d699f3b/attachment-0001.html>

------------------------------

Message: 21
Date: Wed, 13 Nov 2013 19:15:44 -0800
From: Joe Gordon <joe.gordon0 at gmail.com>
To: OpenStack Development Mailing List
        <openstack-dev at lists.openstack.org>
Subject: [openstack-dev]  Gate Math or why you you keep typing
        'recheck'
Message-ID:
        <CAHXdxOfFi56U8pKVU90MANkprgO04VODT+Vqe_m36tin=NU1Jg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi All,

TL;DR: Failure rate for gate jobs in graphite
http://tinyurl.com/mqju53r <http://tinyurl.com/mqju53r>

I am sure many of you are wondering why you keep having to type 'recheck
bug x' all the time (I know I am), so I will try to answer that question
here.

Just before releasing Havana we started elastic-recheck to get a better
grasp on what transient issues the gate is having. This has helped us
classify the types of bugs we have and how often they occur[1] but it
doesn't completely explain why the gate appears to fail so often.

Assuming all tests are independent, the probability that you will need to
run a recheck, is the sum of all tests and each patch commonly has several
revisions so a fairly low failure rate can quickly cause you to use a
recheck.

Or in a simple equation:

percent_need_a_recheck_per_review  = failure_rate * tempest_jobs *
patch_revisions


It turns out we have a graphite server, and after spending too much time on
it, below[2] is the percent failure rate for:
* gate-tempest-devstack-vm-full
* gate-tempest-devstack-vm-neutron
* check-tempest-devstack-vm-neutron
* check-tempest-devstack-vm-full

So with each job failing between 5 to 10% of the time.

now to estimate percent_need_a_recheck_per_review.

lower bound
=========
assumptions:
  - 2 revisions + 1 gate run,
  -  only count big tempest runs: full, neutron, postgres-full
  - failure_rate of 5%
percent_need_a_recheck_per_review = 0.05 * 3 * 3 = 45%

So on a good day you may only have to run a recheck on just under half of
your reviews

upper bound
=========
assumptions:
  - 5 revisions + 1 gate run,
  -  count gating tests that runs tempest: full, neutron, postgres-full,
large-ops, grenade
  - failure_rate of 10%
percent_need_a_recheck_per_review = 0.10 * 5 * 6 = 300%

But on a bad day you may need 3 rechecks to get your patch merged!


In short, even tiny bugs in gate have a major impact on the stability of
gate!  And as we grow the number of integrated projects and increase the
number of tests this pattern will only get worse.


[1] http://status.openstack.org/elastic-recheck/
[2] http://tinyurl.com/mqju53r  <http://tinyurl.com/mqju53r>


Best,
Joe Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/9ac366ce/attachment-0001.html>

------------------------------

Message: 22
Date: Thu, 14 Nov 2013 07:22:53 +0400
From: Lari Partanen <lari.partanen at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] Using custom IPAM with OpenStack
Message-ID: <CCE1116B-CACB-4277-B000-4CDD528673FE at gmail.com>
Content-Type: text/plain; charset=us-ascii

Hi,

our company is using an IPAM solution that we would like to integrate with OpenStack. The idea would be that when instances request IP addresses they would get a free IP address from our IPAM which would be then allocated to them and when instances are deleted the IP addresses are released from the IPAM.

I've gone through the source code but I'm having hard time figuring out how should I proceed with the integration. I would be grateful on information about what methods I should be looking for in the source code and how to extend them properly.

Thanks!


------------------------------

Message: 23
Date: Wed, 13 Nov 2013 19:26:17 -0800
From: Clint Byrum <clint at fewbar.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [ALL] Removing generate_uuid() from
        uuidutils
Message-ID: <1384392237-sup-9647 at clint-HP>
Content-Type: text/plain; charset=UTF-8

Excerpts from Michael Still's message of 2013-11-13 13:24:52 -0800:
> On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <eric at cloudscaling.com> wrote:
>
> > I don't think it is a problem to remove the code in oslo first, as
> > long as no other oslo-incubator code uses it. Projects don't have to
> > sync the code and could always revert should that they do.
>
> I strongly disagree. It stops projects from syncing with oslo until
> they go through the code churn to remove the method.
>
> > However, like Mark, I'm inclined to consider the value of
> > is_uuid_like. While undoubtedly useful, is one method sufficient to
> > warrant creating a new top-level module. Waiting for it to hit the
> > standard library will take quite a long time...
> >
> > There are other components of oslo that are terse and questionable as
> > standalone libraries. For these, it might make sense to aggressively
> > consider rolling some modules together?
> >
> > One clear example would be log.py and log_handler.py, another would be
> > periodic_task.py and loopingcall.py
>
> I'm not sure I see the harm in leaving small but widely used modules
> in oslo incubator. If we really want to release everything as a
> library, can't we just have a generic catchall one for the small
> things? oslo.therest perhaps?

It seems to me that we have two different encodetures in oslo:

1) Useful reusable code. config, logging, db access, etc.
2) Common OpenStack conventions/formats/etc.

Our usage of this module is just a level of indirection for all of us
to share. I don't mind having a tiny library that makes things more
consistent.

I suggest that if something is found to be a common OpenStack convention,
it can go in a library that we call something clever, like "kevin", or
"oslo.common".



------------------------------

Message: 24
Date: Thu, 14 Nov 2013 16:30:31 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Gate Math or why you you keep typing
        'recheck'
Message-ID:
        <CAJ3HoZ3s1Cwu9vcRujihocAdNmr2jVxfAjcHqDD+xja5giBU7A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 14 November 2013 16:15, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> Hi All,
>
> TL;DR: Failure rate for gate jobs in graphite http://tinyurl.com/mqju53r
...
> In short, even tiny bugs in gate have a major impact on the stability of
> gate!  And as we grow the number of integrated projects and increase the
> number of tests this pattern will only get worse.

Thanks for the analysis!

I have two comments (yes, only two!)

Firstly, 5% isn't a tiny bug. It's a huge bug. We're doing thousands
of runs a day. A tiny bug IMO 0.01% occurrence rate or less. Lets
recalibrate our head around failure rates:
a 0.01% failure in a 10K node cloud doing deploys once a day will
happen every day (on average :)).

Secondly, Google in their testing talks say they've basically given up
on the idea that they can eliminate all such issues in automated tests
- in their opinion it's an engineering tradeoff... I think we can do
better :) - I'd like to see us start running 5 or 10 duplicate
scenarios to set a lower bound on flakey tests that can enter the
system /at all/, and to look for and back out changes that introduce
more subtle flakey bugs.

-Rob

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 25
Date: Thu, 14 Nov 2013 09:13:58 +0530
From: Noorul Islam K M <noorul at noorul.com>
To: Doug Hellmann <doug.hellmann at dreamhost.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Solum] Command Line Interface for Solum
Message-ID: <877gcb7im9.fsf at noman.maa.corp.collab.net>
Content-Type: text/plain

Doug Hellmann <doug.hellmann at dreamhost.com> writes:

> On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M <noorul at noorul.com>wrote:
>
>>
>> Hello all,
>>
>> I registered a new blueprint [1] for command line client interface for
>> Solum. We need to decide whether we should have a separate repository
>> for this or go with new unified CLI framework [2]. Since Solum is not
>> part of OpenStack I think it is not the right time to go with the
>> unified CLI.
>>
>
> One of the key features of the cliff framework used for the unified command
> line app is that the subcommands can be installed independently of the main
> program. So you can write plugins that work with the openstack client, but
> put them in the solum client library package (and source repository). That
> would let you, for example:
>
>   $ pip install python-solumclient
>   $ pip install python-openstackclient
>   $ openstack solum make me a paas
>
> Dean has done a lot of work to design a consistent "noun-followed-by-verb"
> command structure, so please look at that work when picking subcommand
> names (for example, you shouldn't use solum as a prefix as I did in my
> example above, since we are removing the project names from the commands).
>

I think we should follow this. If others have no objection, I will
submit a review to openstack-infra/config to create a new repository
named python-solumclient with intial code from cookiecutter template.

Adrian,

Does this blue-print require to be in Approved state to perform
above task?

Thanks and Regards
Noorul

> Doug
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



------------------------------

Message: 26
Date: Wed, 13 Nov 2013 19:44:47 -0800
From: Sumit Naiksatam <sumitnaiksatam at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Using custom IPAM with OpenStack
Message-ID:
        <CAMWrLvi+xrjxvUZCy_krafhbZxJxC5U_XE7+VH+mmBrn7FfeeQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

You can take a look at the patches in this blueprint:
https://blueprints.launchpad.net/neutron/+spec/configurable-ip-allocation

There was also a bp created earlier to talk to an external IPAM:
https://blueprints.launchpad.net/neutron/+spec/neutron-ipam

Thanks,
~Sumit.


On Wed, Nov 13, 2013 at 7:22 PM, Lari Partanen <lari.partanen at gmail.com>wrote:

> Hi,
>
> our company is using an IPAM solution that we would like to integrate with
> OpenStack. The idea would be that when instances request IP addresses they
> would get a free IP address from our IPAM which would be then allocated to
> them and when instances are deleted the IP addresses are released from the
> IPAM.
>
> I've gone through the source code but I'm having hard time figuring out
> how should I proceed with the integration. I would be grateful on
> information about what methods I should be looking for in the source code
> and how to extend them properly.
>
> Thanks!
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/79a00730/attachment-0001.html>

------------------------------

Message: 27
Date: Thu, 14 Nov 2013 12:47:53 +0900
From: Nachi Ueno <nachi at ntti3.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Cc: Sumit Naiksatam <sumit.naiksatam at bigswitch.com>
Subject: Re: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CABJepwjB6yZw_paoC6eVgeimfonfManbQiTKmKDN9JGsAA7hJA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Salvatore, Sumit

> Salvatore
Thank you for your comment. I replied on the google doc.

> Sumit
I think we need also API testing anyway (including negative test).
My idea is use heat api (heat also has tempest) for scenario testing
for more simplified testing code.
The good point of this is we can recreate the same env with tempest
just using heat.

sometimes, it is hard to debug because tempest cleanup resources.
If we can use heat too, it should help debugging.

Best
Nachi








2013/11/14 Sumit Naiksatam <sumitnaiksatam at gmail.com>:
> Thanks Nachi. So is the suggestion to not have tempest tests (testing API)
> for each individual service?
>
> ~Sumit.
>
>
> On Wed, Nov 13, 2013 at 5:55 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> Hi Sumit, Eugene
>>
>> How about to have one test scenario for services?
>> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
>> because of utilization of test resources.
>>
>> I wrote my proposal here.
>>
>> https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016
>>
>> I'm thinking about to use Heat for this testing, because we can re-use
>> the heat template.
>>
>> Best
>> Nachi
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



------------------------------

Message: 28
Date: Thu, 14 Nov 2013 03:47:40 +0000
From: Masayuki Igawa <igawa at mxs.nes.nec.co.jp>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [qa] Tracking development of scenario
        tests
Message-ID:
        <F68D05D283CF314C80E410C21897B8110A107F at BPXM01GP.gisp.nec.co.jp>
Content-Type: text/plain; charset="iso-2022-jp"

Hi,

2013/11/14 11:32:41 David Kranz <dkranz at redhat.com> wrote:
?Re: [openstack-dev] [qa] Tracking development of scenario tests?
> On 11/13/2013 07:35 PM, Christopher Yeoh wrote:
>
>
>       On Thu, Nov 14, 2013 at 9:54 AM, David Kranz <dkranz at redhat.com> wrote:
>
>
>               It was clear at the summit that there is a pressing need for more scenario tests. A number of folks have volunteered to participate so we need a way to track progress and avoid duplication. We have not had great satisfaction using either bugs or blueprints, so Sean and I are proposing a more "self-service" approach and process:
>
>               1. Developer checks in the zeroth version of a scenario test as work in progress. It contains a description of the test, and     possibly work items.  This will "claim" the area of the proposed scenario to avoid duplication and allow others to comment through gerrit.
>
>
>
>       I don't know how well it maps for scenario testing, but I think the spreadsheet approach for the API tests has worked pretty well. Makes the breakdown of large chunks of work more manageable
>
>
>       Chris
>
>       _______________________________________________
>       OpenStack-dev mailing list
>       OpenStack-dev at lists.openstack.org
>       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Yeah, I thought about that. It works well when the spec is a collection of independent one-liners like it is for apis but scenarios are more involved. I also like the idea of putting the spec together with the code and the commenting utility of gerrit. We thought it was worth a try.

I think etherpads is useful for the first step.
Of course, more systematic/automatic approach as David said is better. I have no idea for now, though..

Best Regards,
-- Masayuki Igawa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6609 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/8b5b998c/attachment-0001.bin>

------------------------------

Message: 29
Date: Thu, 14 Nov 2013 14:32:02 +1000
From: Lana Brindley <openstack at lanabrindley.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] libvirt_type Doc Bug
Message-ID: <52845242.3030605 at lanabrindley.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi everyone,

I'm a new tech writer on the team. I was going through bugs and came
across this little gem:

https://bugs.launchpad.net/openstack-manuals/+bug/1195361

It looks as though it was decided that no code changes were required,
but a doc update was. However, I'm struggling to work out what the user
impact is here. On the surface it seems as though it's saying that QEMU
will always be returned as the hypervisor type, and I'm not sure that's
something we should be telling users in so many words (it's not a bug,
it's a feature?)

Can anyone give me a little guidance on this one?

Thanks,
Lana

--
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



------------------------------

Message: 30
Date: Thu, 14 Nov 2013 10:19:56 +0530
From: Sankarshan Mukhopadhyay <sankarshan.mukhopadhyay at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] libvirt_type Doc Bug
Message-ID:
        <CAJWA-5acN_O6sjc94SfShqeVdn3xHKitdL+uPJu2vz4AZoQdsA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 14, 2013 at 10:02 AM, Lana Brindley
<openstack at lanabrindley.com> wrote:
> It looks as though it was decided that no code changes were required, but a
> doc update was. However, I'm struggling to work out what the user impact is
> here. On the surface it seems as though it's saying that QEMU will always be
> returned as the hypervisor type, and I'm not sure that's something we should
> be telling users in so many words (it's not a bug, it's a feature?)

As per <https://bugs.launchpad.net/openstack-manuals/+bug/1195361/comments/4>
if, "kvm" is not a valid value, then it is appropriate to mention that
qemu is the only valid value available for hypervisor_type


--
sankarshan mukhopadhyay
<https://twitter.com/#!/sankarshan>



------------------------------

Message: 31
Date: Thu, 14 Nov 2013 12:56:32 +0800
From: Alex Xu <xuhj at linux.vnet.ibm.com>
To: David Kranz <dkranz at redhat.com>, "All Things QA."
        <openstack-qa at lists.openstack.org>
Cc: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [openstack-qa] [qa][nova] The document
        for the changes from Nova v2 api to v3
Message-ID: <52845800.6070306 at linux.vnet.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 2013?11?14? 05:22, David Kranz wrote:
> On 11/13/2013 08:30 AM, Alex Xu wrote:
>> Hi, guys
>>
>> This is the document for the changes from Nova v2 api to v3:
>> https://wiki.openstack.org/wiki/NovaAPIv2tov3
>> I will appreciate if anyone can help for review it.
>>
>> Another problem comes up - how to keep the doc updated. So can we ask
>> people, who change
>> something of api v3, update the doc accordingly? I think it's a way
>> to resolve it.
>>
>> Thanks
>> Alex
>>
>>
>>
>> _______________________________________________
>> openstack-qa mailing list
>> openstack-qa at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
> Thanks, this is great. I fixed a bug in the os-services section. BTW,
> openstack-qa at lists.openstack.org list is obsolete. openstack-dev with
> subject starting with [qa] is the current "qa list". About updating, I
> think this will have to be heavily socialized in the nova team. The
> initial review should happen by those reviewing the tempest v3 api
> changes. That is how I found the os-services bug.
>
>  -David
Thanks for the bug fix and reminder.  The initial review happen by
reviewing tempest v3 api changes, that make sense for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/fd8ab4aa/attachment-0001.html>

------------------------------

Message: 32
Date: Thu, 14 Nov 2013 08:59:15 +0400
From: Eugene Nikanorov <enikanorov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Cc: Sumit Naiksatam <sumit.naiksatam at bigswitch.com>
Subject: Re: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CAJfiwOTAaMOe1AGOYB0vmKb0_j4H2dA-_GUHDL18-dPfV1UcNw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Nachi and folks,

Thanks for bringing this up.
We started working on basic scenario testing for lbaas using tempest
clients.
We'll consider using heat for it.
However I think we'll get something simple working at first (since we're
not yet experts in tempest) then move to more complex topologies and
scenarios.

Thanks,
Eugene.


On Thu, Nov 14, 2013 at 7:47 AM, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Salvatore, Sumit
>
> > Salvatore
> Thank you for your comment. I replied on the google doc.
>
> > Sumit
> I think we need also API testing anyway (including negative test).
> My idea is use heat api (heat also has tempest) for scenario testing
> for more simplified testing code.
> The good point of this is we can recreate the same env with tempest
> just using heat.
>
> sometimes, it is hard to debug because tempest cleanup resources.
> If we can use heat too, it should help debugging.
>
> Best
> Nachi
>
>
>
>
>
>
>
>
> 2013/11/14 Sumit Naiksatam <sumitnaiksatam at gmail.com>:
> > Thanks Nachi. So is the suggestion to not have tempest tests (testing
> API)
> > for each individual service?
> >
> > ~Sumit.
> >
> >
> > On Wed, Nov 13, 2013 at 5:55 PM, Nachi Ueno <nachi at ntti3.com> wrote:
> >>
> >> Hi Sumit, Eugene
> >>
> >> How about to have one test scenario for services?
> >> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
> >> because of utilization of test resources.
> >>
> >> I wrote my proposal here.
> >>
> >>
> https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016
> >>
> >> I'm thinking about to use Heat for this testing, because we can re-use
> >> the heat template.
> >>
> >> Best
> >> Nachi
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/bfd6aea0/attachment-0001.html>

------------------------------

Message: 33
Date: Thu, 14 Nov 2013 13:11:53 +0800
From: Alex Xu <xuhj at linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [openstack-qa] [qa][nova] The document
        for the changes from Nova v2 api to v3
Message-ID: <52845B99.4000605 at linux.vnet.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 2013?11?14? 07:09, Christopher Yeoh wrote:
> On Thu, Nov 14, 2013 at 7:52 AM, David Kranz <dkranz at redhat.com
> <mailto:dkranz at redhat.com>> wrote:
>
>     On 11/13/2013 08:30 AM, Alex Xu wrote:
>>     Hi, guys
>>
>>     This is the document for the changes from Nova v2 api to v3:
>>     https://wiki.openstack.org/wiki/NovaAPIv2tov3
>>     I will appreciate if anyone can help for review it.
>>
>>     Another problem comes up - how to keep the doc updated. So can we
>>     ask people, who change
>>     something of api v3, update the doc accordingly? I think it's a
>>     way to resolve it.
>>
>>     Thanks
>>     Alex
>>
>>
>>
>>     _______________________________________________
>>     openstack-qa mailing list
>>     openstack-qa at lists.openstack.org  <mailto:openstack-qa at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>     Thanks, this is great. I fixed a bug in the os-services section.
>     BTW, openstack-qa at lists.openstack.org
>     <mailto:openstack-qa at lists.openstack.org> list is obsolete.
>     openstack-dev with subject starting with [qa] is the current "qa
>     list". About updating, I think this will have to be heavily
>     socialized in the nova team. The initial review should happen by
>     those reviewing the tempest v3 api changes. That is how I found
>     the os-services bug.
>
>
> Can we leverage off the DocImpact flag with the commit message somehow
> - say anytime there is a changeset
> with DocImpact and that changes a file under
> nova/api/openstack/compute we generate a notification?
>
> I think we're getting much better at enforcing the DocImpact flag
> during reviews.
+1 for DocImpact flag, that's good idea.
>
> Chris.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/c0277841/attachment-0001.html>

------------------------------

Message: 34
Date: Thu, 14 Nov 2013 06:23:22 +0100
From: Giulio Fidente <gfidente at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [qa] Tracking development of scenario
        tests
Message-ID: <52845E4A.6000508 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 11/14/2013 12:24 AM, David Kranz wrote:
> 1. Developer checks in the zeroth version of a scenario test as work in
> progress. It contains a description of the test, and     possibly work
> items.  This will "claim" the area of the proposed scenario to avoid
> duplication and allow others to comment through gerrit.
> 2. The developer pushes new versions, removing work in progress if the
> code is in working state and a review is desired and/or others will be
> contributing to the scenario.
> 3. When finished, any process-oriented content such as progress tracking
> is removed and the test is ready for final review.

+1 , the description will eventually contribute to documenting the scenarios

yet the submitter (step 1) remains in charge of adding to the draft the
reviewers

how about we map at least one volunteer to each service (via the HACKING
file) and ask submitters to add such a person as reviewer of its drafts
when the tests touch the service? this should help avoid tests duplication.

I very much like the idea of using gerrit for this
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: giulivo



------------------------------

Message: 35
Date: Thu, 14 Nov 2013 14:23:04 +0900
From: Nachi Ueno <nachi at ntti3.com>
To: Eugene Nikanorov <enikanorov at mirantis.com>
Cc: Sumit Naiksatam <sumit.naiksatam at bigswitch.com>, "OpenStack
        Development Mailing List \(not for usage questions\)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neturon][Tempest] A test scenario for
        services
Message-ID:
        <CABJepwg+-cBRyuhdRzmP1ALiUu4r4r84bHQB6msRKWaGE3JVrA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Eugene

Thanks.
Anyway, we need more API test for each services with fine coverage.
so if using only tempest is simple for you, please continue it.

I'll create the heat template mentioned in the slide.
so we can use that.

Best
Nachi


2013/11/14 Eugene Nikanorov <enikanorov at mirantis.com>:
> Hi Nachi and folks,
>
> Thanks for bringing this up.
> We started working on basic scenario testing for lbaas using tempest
> clients.
> We'll consider using heat for it.
> However I think we'll get something simple working at first (since we're not
> yet experts in tempest) then move to more complex topologies and scenarios.
>
> Thanks,
> Eugene.
>
>
> On Thu, Nov 14, 2013 at 7:47 AM, Nachi Ueno <nachi at ntti3.com> wrote:
>>
>> Hi Salvatore, Sumit
>>
>> > Salvatore
>> Thank you for your comment. I replied on the google doc.
>>
>> > Sumit
>> I think we need also API testing anyway (including negative test).
>> My idea is use heat api (heat also has tempest) for scenario testing
>> for more simplified testing code.
>> The good point of this is we can recreate the same env with tempest
>> just using heat.
>>
>> sometimes, it is hard to debug because tempest cleanup resources.
>> If we can use heat too, it should help debugging.
>>
>> Best
>> Nachi
>>
>>
>>
>>
>>
>>
>>
>>
>> 2013/11/14 Sumit Naiksatam <sumitnaiksatam at gmail.com>:
>> > Thanks Nachi. So is the suggestion to not have tempest tests (testing
>> > API)
>> > for each individual service?
>> >
>> > ~Sumit.
>> >
>> >
>> > On Wed, Nov 13, 2013 at 5:55 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>> >>
>> >> Hi Sumit, Eugene
>> >>
>> >> How about to have one test scenario for services?
>> >> IMO, we need to combine LBaaS, FWaaS, VPNaaS scenario tests
>> >> because of utilization of test resources.
>> >>
>> >> I wrote my proposal here.
>> >>
>> >>
>> >> https://docs.google.com/presentation/d/1gu12liw-9el_pR_FDQ7qDRuFpnSXxVzOsp6K0ZzX-_o/edit#slide=id.g295949ab9_016
>> >>
>> >> I'm thinking about to use Heat for this testing, because we can re-use
>> >> the heat template.
>> >>
>> >> Best
>> >> Nachi
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>



------------------------------

Message: 36
Date: Thu, 14 Nov 2013 05:27:25 +0000
From: Joshua Harlow <harlowja at yahoo-inc.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>, Clint Byrum <clint at fewbar.com>
Subject: Re: [openstack-dev] [ALL] Removing generate_uuid() from
        uuidutils
Message-ID: <CEA99F27.4CB1F%harlowja at yahoo-inc.com>
Content-Type: text/plain; charset="us-ascii"

I prefer the library to be named 'josh', kthxbye ;)

On 11/13/13 7:26 PM, "Clint Byrum" <clint at fewbar.com> wrote:

>Excerpts from Michael Still's message of 2013-11-13 13:24:52 -0800:
>> On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <eric at cloudscaling.com>
>>wrote:
>>
>> > I don't think it is a problem to remove the code in oslo first, as
>> > long as no other oslo-incubator code uses it. Projects don't have to
>> > sync the code and could always revert should that they do.
>>
>> I strongly disagree. It stops projects from syncing with oslo until
>> they go through the code churn to remove the method.
>>
>> > However, like Mark, I'm inclined to consider the value of
>> > is_uuid_like. While undoubtedly useful, is one method sufficient to
>> > warrant creating a new top-level module. Waiting for it to hit the
>> > standard library will take quite a long time...
>> >
>> > There are other components of oslo that are terse and questionable as
>> > standalone libraries. For these, it might make sense to aggressively
>> > consider rolling some modules together?
>> >
>> > One clear example would be log.py and log_handler.py, another would be
>> > periodic_task.py and loopingcall.py
>>
>> I'm not sure I see the harm in leaving small but widely used modules
>> in oslo incubator. If we really want to release everything as a
>> library, can't we just have a generic catchall one for the small
>> things? oslo.therest perhaps?
>
>It seems to me that we have two different encodetures in oslo:
>
>1) Useful reusable code. config, logging, db access, etc.
>2) Common OpenStack conventions/formats/etc.
>
>Our usage of this module is just a level of indirection for all of us
>to share. I don't mind having a tiny library that makes things more
>consistent.
>
>I suggest that if something is found to be a common OpenStack convention,
>it can go in a library that we call something clever, like "kevin", or
>"oslo.common".
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




------------------------------

Message: 37
Date: Thu, 14 Nov 2013 06:31:33 +0100
From: Jaume Devesa <devvesa at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto
        Association
Message-ID:
        <CABvUA7kO7LZ-rf7svu7H+f1JvsbS7kqk+_KDvTMu6CyHcUF1zw at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

Hi all,

I see it has been passed two weeks since first mail in this thread and that
blueprint still without assignee. I also think this is a good option for my
first blueprint. However, I can not assign blueprints to myself, only bugs.
Can anybody assign to me?

Steven: if you still interested in it, please tell us. You asked for it
first and it will be yours.

Regards


On 5 November 2013 07:21, Salvatore Orlando <sorlando at nicira.com> wrote:

> I don't think there has been any development in the past 6 months.
> A few people have shown interest in it in the past, but the blueprint has
> currently no assignee.
> So If you want to work on it, feel free to assign to yourself.
>
> To quickly sum up the discussion around this blueprint, it could be
> implemented in two ways:
> - providing automation in the neutron API (creating the floating IP
> together with the port)
> - automating the operation on the orchestration side (nova-api in this
> case).
>
> There are pro and cons in both solutions. In my humble opinion, the only
> thing I would care of is that the existing operation in the Neutron API
> stay "atomic" as they are.
>
> Regards,
> Salvatore
>
>
> On 30 October 2013 08:46, Steven Weston <steven-weston at live.com> wrote:
>
>> Does anybody know what the status of this Blueprint is?
>> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
>>
>>
>>
>> I am new to the neutron developer community and I am looking for a first
>> project ? this might be a good place to start.  But the last update was in
>> March of this year, so I don?t know if the specifications have been locked
>> down yet.
>>
>>
>>
>> Anybody?
>>
>>
>>
>> Thanks!
>>
>> Steven Weston
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/965fb036/attachment-0001.html>

------------------------------

Message: 38
Date: Thu, 14 Nov 2013 09:32:05 +0400
From: Lari Partanen <lari.partanen at gmail.com>
To: sumitnaiksatam at gmail.com
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Using custom IPAM with OpenStack
Message-ID: <3678549A-D23E-4A41-A0EE-421CFA708323 at gmail.com>
Content-Type: text/plain; charset="us-ascii"

Thanks! So _generate_ip @ neutron.db.db_base_plugin_v2.py is one of the methods I need to modify. Is there something like this
http://docs.openstack.org/developer/nova/devref/hooks.html in Neutron for extending its methods or do I need to make a patch
if I wish to distribute my changes?

Regards,
Lari
> Hi,
>
> You can take a look at the patches in this blueprint:
> https://blueprints.launchpad.net/neutron/+spec/configurable-ip-allocation
>
> There was also a bp created earlier to talk to an external IPAM:
> https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
>
> Thanks,
> ~Sumit.
>
>
> On Wed, Nov 13, 2013 at 7:22 PM, Lari Partanen <lari.partanen at gmail.com>wrote:
>
> > Hi,
> >
> > our company is using an IPAM solution that we would like to integrate with
> > OpenStack. The idea would be that when instances request IP addresses they
> > would get a free IP address from our IPAM which would be then allocated to
> > them and when instances are deleted the IP addresses are released from the
> > IPAM.
> >
> > I've gone through the source code but I'm having hard time figuring out
> > how should I proceed with the integration. I would be grateful on
> > information about what methods I should be looking for in the source code
> > and how to extend them properly.
> >
> > Thanks!
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/f46c0e7f/attachment-0001.html>

------------------------------

Message: 39
Date: Wed, 13 Nov 2013 22:47:08 -0700
From: Steven Weston <steven-weston at live.com>
To: "'OpenStack Development Mailing List \(not for usage questions\)'"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto
        Association
Message-ID: <COL401-EAS30397408AC7377B4D478F2585F80 at phx.gbl>
Content-Type: text/plain; charset="us-ascii"

Thanks for the responses on this.  I definitely still interested in
implementing the functionality described in this blueprint, but have been
reluctant to start on it since I did not get a response.



Yes, please assign it to me and I will get started on it right away!  I do
not seem to have the capability to assign it to myself.



Steven



From: Jaume Devesa [mailto:devvesa at gmail.com]
Sent: Wednesday, November 13, 2013 10:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto
Association



Hi all,

I see it has been passed two weeks since first mail in this thread and that
blueprint still without assignee. I also think this is a good option for my
first blueprint. However, I can not assign blueprints to myself, only bugs.
Can anybody assign to me?

Steven: if you still interested in it, please tell us. You asked for it
first and it will be yours.

Regards



On 5 November 2013 07:21, Salvatore Orlando <sorlando at nicira.com
<mailto:sorlando at nicira.com> > wrote:

I don't think there has been any development in the past 6 months.

A few people have shown interest in it in the past, but the blueprint has
currently no assignee.

So If you want to work on it, feel free to assign to yourself.



To quickly sum up the discussion around this blueprint, it could be
implemented in two ways:

- providing automation in the neutron API (creating the floating IP together
with the port)

- automating the operation on the orchestration side (nova-api in this
case).



There are pro and cons in both solutions. In my humble opinion, the only
thing I would care of is that the existing operation in the Neutron API stay
"atomic" as they are.



Regards,

Salvatore



On 30 October 2013 08:46, Steven Weston <steven-weston at live.com
<mailto:steven-weston at live.com> > wrote:

Does anybody know what the status of this Blueprint is?
https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip



I am new to the neutron developer community and I am looking for a first
project - this might be a good place to start.  But the last update was in
March of this year, so I don't know if the specifications have been locked
down yet.



Anybody?



Thanks!

Steven Weston



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/1c632b7a/attachment-0001.html>

------------------------------

Message: 40
Date: Thu, 14 Nov 2013 16:58:28 +1100
From: Michael Still <mikal at stillhq.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] libvirt_type Doc Bug
Message-ID:
        <CAEd1pt4TaoaNJKwKYOW4d8peE-YZKLtTyxWQOTjbERihx-TpSA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 14, 2013 at 3:49 PM, Sankarshan Mukhopadhyay
<sankarshan.mukhopadhyay at gmail.com> wrote:
> On Thu, Nov 14, 2013 at 10:02 AM, Lana Brindley
> <openstack at lanabrindley.com> wrote:
>> It looks as though it was decided that no code changes were required, but a
>> doc update was. However, I'm struggling to work out what the user impact is
>> here. On the surface it seems as though it's saying that QEMU will always be
>> returned as the hypervisor type, and I'm not sure that's something we should
>> be telling users in so many words (it's not a bug, it's a feature?)
>
> As per <https://bugs.launchpad.net/openstack-manuals/+bug/1195361/comments/4>
> if, "kvm" is not a valid value, then it is appropriate to mention that
> qemu is the only valid value available for hypervisor_type

Isn't this kind of confusing for users though? My admin told me the
cluster was kvm, but when I ask nova I get qemu?

Michael

--
Rackspace Australia



------------------------------

Message: 41
Date: Thu, 14 Nov 2013 08:11:06 +0200
From: Alex Glikson <GLIKSON at il.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] [Ironic] [TripleO] scheduling flow
        with    Ironic?
Message-ID:
        <OF294827CC.5DC30A02-ONC2257C23.002047C9-C2257C23.0021FED9 at il.ibm.com>
Content-Type: text/plain; charset="us-ascii"

Thanks, I understand the Nova scheduler part. One of the gaps there is
related to the blueprint we have are working on [1]. I was wondering
regarding the role of Ironic, and the exact interaction between the user,
Nova and Ironic.
In particular, initially I thought that Ironic is going to have its own
scheduler, resolving some of the issues and complexity within Nova (which
could focus on VM management, maybe even getting rid of hosts versus
nodes, etc). But it seems that Ironic aims to stay at the level of virt
driver API.. It is a bit unclear to me what is the desired architecture
going forward - e.g., if the idea is to standardize virt driver APIs but
keep the scheduling centralized, maybe we should take the rest of virt
drivers into separate projects as well, and extend Nova to schedule beyond
just compute (if it is already doing so for virt + bare-metal).
Alternatively, each of them could have its own scheduler (like the
approach we took when splitting out cinder, for example) - and then
someone on top (e.g., Heat) would need to do the cross-project logic.
Taking different architectural approaches in different cases confuses me a
bit.

Thanks,
Alex

[1] https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers






From:   Devananda van der Veen <devananda.vdv at gmail.com>
To:     "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>,
Date:   13/11/2013 10:29 PM
Subject:        Re: [openstack-dev] [Nova] [Ironic] [TripleO] scheduling
flow with       Ironic?



On Wed, Nov 13, 2013 at 8:02 AM, Alex Glikson <GLIKSON at il.ibm.com> wrote:
Hi,

Is there a documentation somewhere on the scheduling flow with Ironic?

The reason I am asking is because we would like to get virtualized and
bare-metal workloads running in the same cloud (ideally with the ability
to repurpose physical machines between bare-metal workloads and
virtualized workloads), and would like to better understand where the gaps
are (and potentially help bridging them).

Hi Alex,

Baremetal uses an alternative
scheduler, nova.scheduler.baremetal_host_manager.BaremetalHostManager, so
giving that a read may be helpful. It searches the available list of
baremetal nodes for one that matches the CPU, RAM, and disk capacity of
the requested flavor, and compares the node's extra_specs:cpu_arch to that
of the requested image, then consumes 100% of that node's available
resources. Otherwise, I believe the scheduling flow is basically the same:
http request to n-api, rpc passes to n-scheduler, which selects a node,
and calls to n-conductor & n-cpu to do the work of spawn()ing it.

As far as the gaps in running both baremetal and virtual -- I have been
told by several folks that it's possible to run both baremetal and virtual
hypervisors in the same cloud by using separate regions, or separate
host-aggregates, for the simple reason that these require distinct
nova-scheduler processes. A single scheduler, today, can't serve both. I
haven't seen any docs on how to do this, though.

As for moving a workload between them, the TripleO team has discussed this
and, afaik, decided to hold off working on it for now. It would be better
for them to fill in the details here -- my memory may be wrong, or things
may have changed.

Cheers,
Devananda



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/e5a54b3c/attachment-0001.html>

------------------------------

Message: 42
Date: Thu, 14 Nov 2013 15:13:43 +0900
From: Mitsuru Kanabuchi <kanabuchi.mitsuru at po.ntts.co.jp>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Heat]Updated summit etherpad:
        API-retry-with-idempotency
Message-ID: <20131114151343.df253dd15dad15ab1e1197f9 at po.ntts.co.jp>
Content-Type: text/plain; charset=US-ASCII


Thank you for comments!

On Thu, 14 Nov 2013 11:02:34 +1300
Steve Baker <sbaker at redhat.com> wrote:
> On 11/12/2013 07:40 PM, Mitsuru Kanabuchi wrote:
> (snip)
> Just to confirm, my understanding of the outcome of that session was
> that pythonclients should implement retries of failed requests with the
> idempotency token.
>
> Which means that no changes are required in heat, since the clients are
> attempting the retries inside a single client call.

In my understand, the conclusion of summit discussion doesn't contain about
implementation target(heat or pythonclient).
I think, it needs more discussions.

In my opinion, API-retry function should implement to heat for the following
reasons.

  1) Heat has to judge necessity of API-retry when Heat could get HTTP response.
  2) (Mr.Zane commented) Heat has to delete underlying resource using idempotency
     key when POST retry-over happened.

I think these processing(judge response code and cleanup resource) aren't
pythonclient's work.
What do you think?

On Wed, 13 Nov 2013 23:19:00 +0100
Zane Bitter <zbitter at redhat.com> wrote:
> (snip)
> Assuming this can still fail eventually (even after retries) we still
> need a way in Heat to make sure we can delete the resource by looking it
> up from the idempotency token.
>
> Of course the idempotency token *should* be just the name, but since
> most projects have inexplicably chosen not to enforce unique names (in
> tenant scope), we're in the odd position of requiring 3 ways to look up
> any resource (by name, UUID, and idempotency token). That's bonkers, but
> what can you do?

I agree with you.

We don't want to add new look-up-keys if we could.
Our objective is to solve the problem that is happen when API response is
lost and Client doesn't get resource ID.

Currently, parameters(uuid and name) aren't appropriate for the objective
because these parameters can't get when API response was lost.
There is no way to check resource existence from client side.

I thought Client Token(Idempotency Token?) is best way to cope that circumstance.

  https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token

This blueprint will provide us that Amazon like idempotency functionality.
I really hope the blueprint's discussion will be active more.

On Wed, 13 Nov 2013 16:35:15 -0600
Chris Friesen <chris.friesen at windriver.com> wrote:
> On 11/13/2013 04:19 PM, Zane Bitter wrote:
> (snip)
> Why would the idempotency token not be the UUID?  Presumably that should
> be unique.

I think so too, idempotency token have to be unique.
In addition, the token would generated by each user.
The idempotency token have to be unique per user for avoiding token conflict.

Regards

--------------------
  Mitsuru Kanabuchi
    NTT Software Corporation
    E-Mail : kanabuchi.mitsuru at po.ntts.co.jp




------------------------------

Message: 43
Date: Wed, 13 Nov 2013 22:34:35 -0800
From: Chris Behrens <cbehrens at codestud.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID: <6938E574-E11C-4C2F-A1DA-CE17F0041EB4 at codestud.com>
Content-Type: text/plain; charset=us-ascii


On Nov 13, 2013, at 6:55 PM, Robert Collins <robertc at robertcollins.net> wrote:

> On 14 November 2013 15:28, Chris Behrens <cbehrens at codestud.com> wrote:
>> For this example, I'd look at using parens on the left side to see if that helps.  I also, like Sean, really dislike the look of \.
>
> I dislike \ most of the time too :).
>

:)

>
>>>> (foo, bar, baz =
>  File "<stdin>", line 1
>    (foo, bar, baz =
>                   ^
> SyntaxError: invalid syntax

Right.  I was thinking something like this:

(folder_exists, file_exists,
 file_size_in_kb, disk_extents) = self._path_file_exists(ds_browser,
                                                                                       folder_path,
                                                                                       file_name)

Or something similar.

- Chris




------------------------------

Message: 44
Date: Thu, 14 Nov 2013 19:40:05 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] libvirt_type Doc Bug
Message-ID:
        <CAJ3HoZ2OK4ZuUb+gfFso2hEY=3wksvW=WpNZvSOatrS97_5tfA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Seems super confusing to me : this is a technical accuracy (qemu and
kvm use the same codepath in libvirt for conf and spawn etc) trumping
user interface (qemu and kvm are very very different in terms of
performance and many capabilities (e.g. > 2GB ram in an instance)..

-Rob

On 14 November 2013 18:58, Michael Still <mikal at stillhq.com> wrote:
> On Thu, Nov 14, 2013 at 3:49 PM, Sankarshan Mukhopadhyay
> <sankarshan.mukhopadhyay at gmail.com> wrote:
>> On Thu, Nov 14, 2013 at 10:02 AM, Lana Brindley
>> <openstack at lanabrindley.com> wrote:
>>> It looks as though it was decided that no code changes were required, but a
>>> doc update was. However, I'm struggling to work out what the user impact is
>>> here. On the surface it seems as though it's saying that QEMU will always be
>>> returned as the hypervisor type, and I'm not sure that's something we should
>>> be telling users in so many words (it's not a bug, it's a feature?)
>>
>> As per <https://bugs.launchpad.net/openstack-manuals/+bug/1195361/comments/4>
>> if, "kvm" is not a valid value, then it is appropriate to mention that
>> qemu is the only valid value available for hypervisor_type
>
> Isn't this kind of confusing for users though? My admin told me the
> cluster was kvm, but when I ask nova I get qemu?
>
> Michael
>
> --
> Rackspace Australia
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 45
Date: Wed, 13 Nov 2013 22:44:01 -0800
From: Mike Perez <thingee at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] RFC: reverse the default Gerrit sort
        order
Message-ID:
        <CAHcn5b2ZweNXAndA+F5P+Bb_6PMs73DMR-kgX3GasdXRZCn4SA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Nov 6, 2013 at 3:36 PM, Robert Collins <robertc at robertcollins.net>wrote:

> I've been thinking about review queues recently (since here at the
> summit everyone is talking about reviews! :)).
>
> One thing that struck me today was that Gerrit makes it easier to
> review the newest changes first, rather than the changes that have
> been in the queue longest, or the changes that started going through
> the review process first.
>
> So... is it possible to change the default sort order for Gerrit? How
> hard is it to do - could we do an experiment on that and see if it
> nudges the dial for reviewstats (just make the change, not ask anyone
> to change their behaviour)?
>
> As for what sort order to choose, I'd be happy just getting data on a
> different default sort order - it seems like the easiest thing would
> be to reverse the current order, vs doing something more
> sophisticated.
>
> If folk are about to jump up and say 'hey, reviewday' or 'hey
> next-review' : I specifically want to see what the effect on changing
> the Gerrit web UI is, because my sense is that that is the default
> place folk do reviews, and I want to change the default-experience
> folk have, not the optional experience folk can opt into.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>


I tend to use this review priority page [1], which appears to give a higher
score to things by age (according to the cinder listing the oldest one has
no bp or bug and is on the top), bp priority, and bug priority.

Now this doesn't stop people from grabbing the first thing on gerrit
reviews, but perhaps we can encourage better practices by where people
usually start [2] and maybe a link to good review workflows [3] on gerrit
itself?

[1] - http://status.openstack.org/reviews
[2] - https://wiki.openstack.org/wiki/How_To_Contribute
[3] - https://wiki.openstack.org/wiki/ReviewWorkflowTips

--
Mike Perez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/85efc56c/attachment-0001.html>

------------------------------

Message: 46
Date: Thu, 14 Nov 2013 19:49:41 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID:
        <CAJ3HoZ11iLpJkTkZ6dyrSLVpXzy+raBBBNKXoNVg4deJ=o-xVA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 14 November 2013 19:34, Chris Behrens <cbehrens at codestud.com> wrote:
>

>>>>> (foo, bar, baz =
>>  File "<stdin>", line 1
>>    (foo, bar, baz =
>>                   ^
>> SyntaxError: invalid syntax
>
> Right.  I was thinking something like this:
>
> (folder_exists, file_exists,
>  file_size_in_kb, disk_extents) = self._path_file_exists(ds_browser,
>                                                                                        folder_path,
>                                                                                        file_name)
>
> Or something similar.

And thus my point is made :>

-Rob

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



------------------------------

Message: 47
Date: Thu, 14 Nov 2013 14:57:29 +0800
From: Zhongyue Luo <zhongyue.nah at intel.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [style] () vs \ continuations
Message-ID:
        <CAFf0h6d1WFFjL1jaR+it6ik2Fh0MturCLe_NEyXcpBMknR=96w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Nov 14, 2013 at 2:34 PM, Chris Behrens <cbehrens at codestud.com>wrote:

>
> On Nov 13, 2013, at 6:55 PM, Robert Collins <robertc at robertcollins.net>
> wrote:
>
> > On 14 November 2013 15:28, Chris Behrens <cbehrens at codestud.com> wrote:
> >> For this example, I'd look at using parens on the left side to see if
> that helps.  I also, like Sean, really dislike the look of \.
> >
> > I dislike \ most of the time too :).
> >
>
> :)
>
> >
> >>>> (foo, bar, baz =
> >  File "<stdin>", line 1
> >    (foo, bar, baz =
> >                   ^
> > SyntaxError: invalid syntax
>
> Right.  I was thinking something like this:
>
> (folder_exists, file_exists,
>  file_size_in_kb, disk_extents) = self._path_file_exists(ds_browser,
>
>              folder_path,
>
>              file_name)
>
>
I've split the line in situations like this in the past to remove
backslashes in Nova.

foo = self._path_file_exists(ds_browser, folder_path, file_name)
folder_exists, file_exists, file_size_in_kb, disk_extents = foo

There should always be a way to avoid backslashes.


> Or something similar.
>
> - Chris
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
*Intel SSG/STO/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/1d911b45/attachment-0001.html>

------------------------------

Message: 48
Date: Wed, 13 Nov 2013 23:02:38 -0800
From: Edgar Magana <emagana at plumgrid.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] New plug-ins requirements
Message-ID:
        <CAH_ayd6ro5qCn7_Ur6oOD1nR0=jr--Gk9FpmJHn1iK0i2jMYUQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Salvatore,

I do agree with you. When I said in my first email "little bit of guidance"
I mean the policy for Icehouse and moving forward. I do not want to make
our PTL angry  :-)

Mark,

I hope you can commend on this thread, otherwise I will bring this topic on
our next IRC meeting.

Thanks,

Edgar


On Wed, Nov 13, 2013 at 7:11 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> I reckon we should wait a little for the PTL to propose a draft of the
> policy we can comment on.
>
> 'thirdy paty test' probably was meant as integration with gerrit (
> http://ci.openstack.org/third_party.html); the test suite to be executed
> is, obviously, the tempest test suite.
> In my opinion, the policy will define criteria for acceptability of
> skipped tests and ability of adding plugin-specific tests.
>
> Regards,
> Salvatore
>
>
> On 12 November 2013 15:15, Kyle Mestery (kmestery) <kmestery at cisco.com>wrote:
>
>> On Nov 12, 2013, at 2:46 AM, Robert Collins <robertc at robertcollins.net>
>> wrote:
>> > On 12 November 2013 21:15, Edgar Magana <emagana at plumgrid.com> wrote:
>> >> Team,
>> >>
>> >> It has been decided during the Icehouse summit that all vendor specific
>> >> plug-ins should enforce remote tempest tests:
>> >> http://ci.openstack.org/third_party.html
>> >>
>> >> I would like to understand if we will apply this rule for any new
>> plug-in
>> >> during Icehouse or we will start applying this new requirement until
>> "J"
>> >> timeframe.
>> >
>> > I can't comment on when - thats a Neutron dev decision, but I heartily
>> > endorse getting all code paths tested asap :).
>> >
>> My personal opinion is if we are going to require all existing Neutron
>> plugins to
>> have valid smokestack tests by Icehouse-2, then any new plugins should not
>> be allowed into the tree without those tests. This includes new Modular
>> Layer 2
>> MechanismDrivers as well.
>>
>> >> I do believe that should enforce this new requirement ASAP but I also
>> >> believe that we need to provide a little bit more of guidance on this
>> >> process.
>> >> So, Besides the above mentioned wiki, is there any more information
>> that we
>> >> can provide about this new requirement? I think we should update
>> Neutron
>> >> wiki with this information.
>> >> If somebody is very familiar with the process will be interested in
>> posting
>> >> their input on this thread.
>> >
>> > I think the requirement of 'use third party tests' is confusing goal
>> > with implementation: the goal should be that 'all vendor plugins be CI
>> > tested at verification level at minimum'. This leaves room for gate
>> > based testing of such plugins too, if the vendor steps up and meets
>> > the requirements to have their plugin be gate checked - which is
>> > superior to merely doing verification checks.
>> >
>> > -Rob
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/ff6eeac8/attachment.html>

------------------------------

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


End of OpenStack-dev Digest, Vol 19, Issue 33
*********************************************




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================