Open Stack

I came across the automatic truncate issue working for a big data analytics
company.  The offending column was a referring url, which normally fits in
the address bar, but occasionally would take up the entire screen.  This
happened in 0.1% of the cases on 1 Tb ingest per day.  Loads could take
upwards of 2 hours, so pre-cleaning all that data was un-desirable.

The url wasn't really needed, as it was hashed to a value for computation,
but data scientists are loathe to throw away any data for any reason.
We were using vertica, which offered only two options which could be set
per load call: truncate silently, or drop the row and send it to a log
file.  In the end, we just truncated, but what we really would have liked
was:

1.  Default: error out with a message indicating which conf file and
parameter could be changed to adjust the setting.
2.  Allow truncate AND log, so we have the best of both worlds.

ps. this is my first post.  I had to copy/paste the previous message and
then edit the message.  Is it possible just to click on the link to message
id and have that automatic?

kesten

Message: 2
Date: Wed, 11 Sep 2013 10:20:18 -0700
From: Clint Byrum <clint at fewbar.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat][oslo] mysql, sqlalchemy and
        sql_mode
Message-ID: <1378919209-sup-3994 at fewbar.com>
Content-Type: text/plain; charset=UTF-8

Excerpts from Steven Hardy's message of 2013-09-11 03:37:40 -0700:
> Hi all,
>
> I'm investigating some issues, where data stored to a text column in mysql
> is silently truncated if it's too big.
>
> It appears that the default configuration of mysql, and the sessions
> established via sqlalchemy is to simply warn on truncation rather than
> raise an error.
>
> This seems to me to be almost never what you want, since on retrieval the
> data is corrupt and bad/unexpected stuff is likely.
>
> This AFAICT is a mysql specific issue[1], which can be resolved by setting
> sql_mode to "traditional"[2,3], after which an error is raised on
truncation,
> allowing us to catch the error before the data is stored.
>
> My question is, how do other projects, or oslo.db, handle this atm?
>
> It seems we either have to make sure the DB enforces the schema/model, or
> validate every single value before attempting to store, which seems like
an
> unreasonable burden given that the schema changes pretty regularly.
>
> Can any mysql, sqlalchemy and oslo.db experts pitch in with opinions on
> this?

I do think that setting stricter sql modes is the right way to go.

Note that I worked around this within Heat for JSON fields thusly:

https://git.openstack.org/cgit/openstack/heat/commit/?id=1e16ed2d

However, I do think we should make it a priority to protect the database
and the entire service from abnormally large values. The moment at which
we are serializing a data structure to the database is a bit late to
mitigate the cost of handling it. Here is an example of the kind of
border protection we need:

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

I want to detect that we overflowed a big column, and I think that if
it ever actually happens, it is a critical bug.



On Wed, Sep 11, 2013 at 11:16 PM, <openstack-dev-request at lists.openstack.org
> wrote:

> Send OpenStack-dev mailing list submissions to
>         openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
>         openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: [savanna] Program name and Mission statement
>       (Michael Basnight)
>    2. Re: [heat][oslo] mysql, sqlalchemy and sql_mode (Clint Byrum)
>    3. Re: [heat][oslo] mysql, sqlalchemy and sql_mode (David Ripton)
>    4. Re: [savanna] Program name and Mission statement (John Speidel)
>    5. Re: Keystone and Multiple Identity Sources (David Chadwick)
>    6. Re: [Neutron] Need some clarity on security group protocol
>       numbers vs names (Akihiro Motoki)
>    7. Re: [Heat] How the autoscale API should control scaling in
>       Heat (Joshua Harlow)
>    8. Re: Keystone and Multiple Identity Sources (Dolph Mathews)
>    9. Re: [Heat] How the autoscale API should control   scaling in
>       Heat (Clint Byrum)
>   10. Re: [Ceilometer] Correct way to disable specific event
>       collection by the collector (Doug Hellmann)
>   11. Re: Keystone and Multiple Identity Sources (Brad Topol)
>   12. Re: [heat] Comments/questions on the
>       instance-group-api-extension blueprint (Mike Spreitzer)
>   13. Re: Keystone and Multiple Identity Sources (David Chadwick)
>   14. Re: [Neutron] Need some clarity on security group protocol
>       numbers vs names (Justin Hammond)
>   15. TC Meeting / Savanna Incubation Follow-Up (Sergey Lukjanov)
>   16. [qa] nominations for tempest-core (Sean Dague)
>   17. Re: [qa] nominations for tempest-core (Matthew Treinish)
>   18. Re: [qa] nominations for tempest-core (Jay Pipes)
>   19. Re: [Neutron] Need some clarity on security group protocol
>       numbers vs names (Mark McClain)
>   20. Re: Keystone and Multiple Identity Sources (Adam Young)
>   21. Re: Keystone and Multiple Identity Sources (Adam Young)
>   22. Re: [qa] nominations for tempest-core (David Kranz)
>   23. Re: Keystone and Multiple Identity Sources (Adam Young)
>   24. [Neutron] New plugin (Marc PINHEDE)
>   25. Re: [Neutron] New plugin (Salvatore Orlando)
>   26. Re: [Neutron] Need some clarity on security group protocol
>       numbers vs names (Arvind Somya (asomya))
>   27. [State-Management] Agenda for tommorow meeting at 2000 UTC
>       (Joshua Harlow)
>   28. Re: [Heat] How the autoscale API should control scaling in
>       Heat (Keith Bray)
>   29. Re: [nova] [pci device passthrough] fails with "NameError:
>       global name '_' is not defined" (yongli he)
>   30. Re: [heat] Comments/questions on the
>       instance-group-api-extension blueprint (shalz)
>   31. [Keystone] Enforcing cert validation in auth_token        middleware
>       (Jamie Lennox)
>   32. Re: [Keystone] Enforcing cert validation in auth_token
>       middleware (Dolph Mathews)
>   33. [nova] FFE Request: image-multiple-location support
>       (lzy.dev at gmail.com)
>   34. Re: [Heat] How the autoscale API should control scaling in
>       Heat (Joshua Harlow)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Sep 2013 10:19:45 -0700
> From: Michael Basnight <mbasnight at gmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [savanna] Program name and Mission
>         statement
> Message-ID: <BB2F15BC-D43A-449C-8C7D-86908AEC26FA at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sep 11, 2013, at 8:42 AM, Andrei Savu wrote:
>
> > +1
> >
> > I guess this will also clarify how Savanna relates to other projects
> like OpenStack Trove.
>
> Yes the conversations around Trove+Savanna will be fun at the summit! I
> see overlap between our missions ;)
>
> >
> > -- Andrei Savu
> >
> > On Wed, Sep 11, 2013 at 5:16 PM, Mike Spreitzer <mspreitz at us.ibm.com>
> wrote:
> > > To provide a simple, reliable and repeatable mechanism by which to
> > > deploy Hadoop and related Big Data projects, including management,
> > > monitoring and processing mechanisms driving further adoption of
> OpenStack.
> >
> > That sounds like it is at about the right level of specificity.
> >
> > _______________________________________________
> > 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 --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/589f89f0/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Sep 2013 10:20:18 -0700
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat][oslo] mysql, sqlalchemy and
>         sql_mode
> Message-ID: <1378919209-sup-3994 at fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Steven Hardy's message of 2013-09-11 03:37:40 -0700:
> > Hi all,
> >
> > I'm investigating some issues, where data stored to a text column in
> mysql
> > is silently truncated if it's too big.
> >
> > It appears that the default configuration of mysql, and the sessions
> > established via sqlalchemy is to simply warn on truncation rather than
> > raise an error.
> >
> > This seems to me to be almost never what you want, since on retrieval the
> > data is corrupt and bad/unexpected stuff is likely.
> >
> > This AFAICT is a mysql specific issue[1], which can be resolved by
> setting
> > sql_mode to "traditional"[2,3], after which an error is raised on
> truncation,
> > allowing us to catch the error before the data is stored.
> >
> > My question is, how do other projects, or oslo.db, handle this atm?
> >
> > It seems we either have to make sure the DB enforces the schema/model, or
> > validate every single value before attempting to store, which seems like
> an
> > unreasonable burden given that the schema changes pretty regularly.
> >
> > Can any mysql, sqlalchemy and oslo.db experts pitch in with opinions on
> > this?
>
> I do think that setting stricter sql modes is the right way to go.
>
> Note that I worked around this within Heat for JSON fields thusly:
>
> https://git.openstack.org/cgit/openstack/heat/commit/?id=1e16ed2d
>
> However, I do think we should make it a priority to protect the database
> and the entire service from abnormally large values. The moment at which
> we are serializing a data structure to the database is a bit late to
> mitigate the cost of handling it. Here is an example of the kind of
> border protection we need:
>
> https://review.openstack.org/#/c/44585/
>
> I want to detect that we overflowed a big column, and I think that if
> it ever actually happens, it is a critical bug.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 11 Sep 2013 13:25:03 -0400
> From: David Ripton <dripton at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [heat][oslo] mysql, sqlalchemy and
>         sql_mode
> Message-ID: <5230A76F.9070002 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 09/11/2013 12:28 PM, Monty Taylor wrote:
> >
> >
> > On 09/11/2013 11:09 AM, David Ripton wrote:
> >> On 09/11/2013 06:37 AM, Steven Hardy wrote:
> >>
> >>> I'm investigating some issues, where data stored to a text column in
> >>> mysql
> >>> is silently truncated if it's too big.
> >>>
> >>> It appears that the default configuration of mysql, and the sessions
> >>> established via sqlalchemy is to simply warn on truncation rather than
> >>> raise an error.
> >>>
> >>> This seems to me to be almost never what you want, since on retrieval
> the
> >>> data is corrupt and bad/unexpected stuff is likely.
> >>>
> >>> This AFAICT is a mysql specific issue[1], which can be resolved by
> >>> setting
> >>> sql_mode to "traditional"[2,3], after which an error is raised on
> >>> truncation,
> >>> allowing us to catch the error before the data is stored.
> >>>
> >>> My question is, how do other projects, or oslo.db, handle this atm?
> >>>
> >>> It seems we either have to make sure the DB enforces the schema/model,
> or
> >>> validate every single value before attempting to store, which seems
> >>> like an
> >>> unreasonable burden given that the schema changes pretty regularly.
> >>>
> >>> Can any mysql, sqlalchemy and oslo.db experts pitch in with opinions on
> >>> this?
> >>
> >> Nova has a PostgreSQL devstack gate, which occasionally catches errors
> >> that MySQL lets through.  For example,
> >> https://bugs.launchpad.net/nova/+bug/1217167
> >>
> >> Unfortunately we have some MySQL-only code, and PostgreSQL obviously
> >> can't catch such errors there.
> >>
> >> I think we should consider turning off auto-truncation for MySQL on our
> >> CI boxes.
> >
> > Should turn it off everywhere - same as how we auto-configure to use
> > InnoDB and not MyISAM, we should definitely set strict sql_modes
> > strings. There is not an operational concern - sql_modes affect app
> > developers, of which we are they. :)
>
> If it's our DB, we can configure it however we want.  If it's a user's
> DB, and it's potentially also used by other programs, then we need to be
> careful.
>
> We can set strict mode either globally for the DB server, or
> per-session.  My gut says we should do it per-session, even though it's
> a bit annoying to run the code every time we start a session rather than
> once at setup, Just In Case someone is running OpenStack on a MySQL
> server that also does other things, and might not appreciate excessive
> global meddling.
>
> Anyway, I'll propose a patch for this in Icehouse.
>
> --
> David Ripton   Red Hat   dripton at redhat.com
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 11 Sep 2013 13:26:05 -0400
> From: John Speidel <jspeidel at hortonworks.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [savanna] Program name and Mission
>         statement
> Message-ID: <5230A7AD.8090502 at hortonworks.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> +1
>
> On 9/11/13 1:13 PM, Matthew Farrellee wrote:
> > That sounds quite good.
> >
> > Best,
> >
> >
> > matt
> >
> > On 09/11/2013 11:42 AM, Andrei Savu wrote:
> >> +1
> >>
> >> I guess this will also clarify how Savanna relates to other projects
> >> like OpenStack Trove.
> >>
> >> -- Andrei Savu
> >>
> >> On Wed, Sep 11, 2013 at 5:16 PM, Mike Spreitzer <mspreitz at us.ibm.com
> >> <mailto:mspreitz at us.ibm.com>> wrote:
> >>
> >>      > To provide a simple, reliable and repeatable mechanism by
> >> which to
> >>      > deploy Hadoop and related Big Data projects, including
> >> management,
> >>      > monitoring and processing mechanisms driving further adoption of
> >>     OpenStack.
> >>
> >>     That sounds like it is at about the right level of specificity.
> >>
> >>     _______________________________________________
> >>     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
> >> 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
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 11 Sep 2013 18:31:31 +0100
> From: David Chadwick <d.w.chadwick at kent.ac.uk>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID: <5230A8F3.9030405 at kent.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Further supplementary information to Adam's email below, is that there
> are already one further federation protocol profiles that has been
> published:
> for an external Keystone acting as an IdP at
> https://review.openstack.org/#/c/42107/
>
> and another for SAML has been prepared and is ready for publication.
>
> I would expect several additional federation profiles to be published in
> the future, for example, for OpenID Connect and what ever else might be
> just around the corner.
>
> Given the fact that the number of federation protocols is not fixed, and
> will evolve with time, then I would prefer their method of integration
> into Keystone to be common, so that one "federation" module can handle
> all the non-protocol specific federation features, such as policy and
> trust checking, and this module can have multiple different protocol
> handling modules plugged into it that deal with the protocol specific
> features only. This is the method we have adopted in our current
> implementation of federation, and have shown that it is a viable and
> efficient way of implementation as we currently support three protocol
> profiles (SAML, ABFAB and External Keystone).
>
> Thus I prefer
>
> "method": "federation" "protocol": "abfab"
>
> in which the abfab part would be replaced by the particular protocol,
> and there are common parameters to be used by the federation module
>
> instead of "method": "abfab"
>
> as the latter removes the common parameters from federation, and also
> means that common code wont be used, unless it is cut and paste into
> each protocol specific module.
>
> Comments?
>
> David
>
>
> On 11/09/2013 16:25, Adam Young wrote:
> > David Chadwick wrote up an in depth API extension for Federation:
> > https://review.openstack.org/#/c/39499
> > There is an abfab API proposal as well:
> > https://review.openstack.org/#/c/42221/
> >
> > After discussing this for a while, it dawned on me that Federation
> > should not be something bolted on to Keystone, but rather that it was
> > already central to the design.
> >
> > The SQL Identity backend is a simple password store that collects users
> > into groups.  This makes it an identity provider (IdP).
> > Now Keystone can register multiple LDAP servers as Identity backends.
> >
> > There are requests for SAML and ABFAB integration into Keystone as well.
> >
> > Instead of a "Federation API"  Keystone should take the key concepts
> > from the API and make them core concepts.  What would this mean:
> >
> > 1.  Instead of "method": "federation" "protocol": "abfab"  it would be
> > "method": "abfab",
> > 2.  The rules about multiple round trips (phase)  would go under the
> > "abfab" section.
> > 3.  There would not be a "protocol_data" section but rather that would
> > be the "abfab" section as well.
> > 4.  Provider ID would be standard in the method specific section.
> >
> > One question that has come up has been about Providers, and whether they
> > should be considered endpoints in the Catalog.  THere is a couple issues
> > wiuth this:  one is that they are not something managed by OpenStack,
> > and two is that they are not necessarily Web Protocols.  As such,
> > Provider should probably be First class citizen.  We already have LDAP
> > handled this way, although not as an enumerated entity.  For the first
> > iteration, I would like to see ABFAB, SAML, and any other protocols we
> > support done the same way as LDAP:  a deliberate configuration option
> > for Keystone that will require a config file change.
> >
> > David and I have discussed this in a side conversation, and agree that
> > it requires wider input.
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 12 Sep 2013 02:46:48 +0900
> From: Akihiro Motoki <amotoki at gmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Need some clarity on security
>         group protocol numbers vs names
> Message-ID:
>         <CALhU9tmsW2QzBV-HxeXM9+5YNUzjPAYPeM_oaqVw=
> TVJh25p6A at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Justin,
>
> My point is what
>
> On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond
> <justin.hammond at rackspace.com> wrote:
> > As it seems the review is no longer the place for this discussion, I will
> > copy/paste my inline comments here:
> >
> > I dislike the idea of passing magical numbers around to define protocols
> > (defined or otherwise). I believe there should be a common set of
> > protocols with their numbers mapped (such as this constants business) and
> > a well defined way to validate/list said common constants.
>
> I agree that value should be validated appropriately in general.
> A configurable list of allowed protocols looks good to me.
>
> > wishes to add support for a protocol outside of the common case, it
> should
> > be added to the list in a pluggable manner.
> > Ex: common defines the constants 1, 6, 17 to be valid but my_cool_plugin
> > wants to support 42. It should be my plugin's responsibility to add 42 to
> > the list of valid protocols by appending to the list given a pluggable
> > interface to do so. I do not believe plugins should continue to update
> the
> > common.constants file with new protocols, but I do believe explicitly
> > stating which protocols are valid is better than allowing users to
> > possibly submit protocols erroneously.
>
> I think this is just a case a backend plugin defines allowed protocols.
>
> I also see a different case: a cloud provider defines allowed protocols.
> For example VLAN network type of OVS plugin can convey any type of packets
> including GRE, STCP and so on if a provider wants to do so.
> We need to allow a provider to configure the list.
>
> Considering the above, what we need to do looks:
> (a) to validate values properly,
> (b) to allow a plugin to define what protocols should be allowed
>     (I think we need two types of lists: possible protocols and
> default allowed protocols)
> (c) to allow a cloud provider (deployer) to customize allow protocols.
>     (Of course (c) is a subnet of "possible protocols" in (b))
>
> Does it make sense?
> The above is just a start point of the discussion and some list can be
> omitted.
>
> # Whether (c) is needed or not depends on the default list of (b).
> # If it is wide enough (c) is not needed. The current list of (b) is
> [tcp, udp, icmp]
> # and it looks too small set to me, so it is better to have (c) too.
>
> > If the plugins use a system such as this, it is possible that new,
> common,
> > protocols can be found to be core. See NETWORK_TYPE constants.
>
> I think the situation is a bit different. What network types are
> allowed is tightly
> coupled with a plugin implementation, and a cloud provider choose a plugin
> based on their needs. Thus the mechanism of NETWORK_TYPE constants
> make sense to me too.
>
> > tl;dr: magic constants are no good, but values should be validated in a
> > pluggable and explicit manner.
>
> As I said above, I agree it is important to validate values properly in
> general.
>
> Thanks,
> Akihiro
>
> >
> >
> >
> > On 9/11/13 10:40 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
> >
> >>Hi all,
> >>
> >>Arvind, thank you for initiate the discussion about the ip protocol in
> >>security group rules.
> >>I think the discussion point can be broken down into:
> >>
> >>(a) how to specify ip protocol : by name, number, or both
> >>(b) what ip protocols can be specified: known protocols only, all
> >>protocols (or some subset of protocols including unknown protocols)
> >>     where "known protocols" is defined as a list in Neutron (a list
> >>of constants or a configurable list)
> >>
> >>------
> >>(b) is the main topic Arvind and I discussed in the review.
> >>If only known protocols are allowed, we cannot allow protocols which
> >>are not listed in the known protocol list.
> >>For instance, if "tcp", "udp" and "icmp" are registered as known
> >>protocols (this is the current neutron implementation),
> >>a tenant cannot allow "stcp" or "gre".
> >>
> >>Pros of "known protocols only" is the infrastructure provider can
> >>control which protocols are allowed.
> >>Cons is that users cannot use ip protocols not listed in a known list
> >>and a provider needs to maintain a known protocol list.
> >>Pros and cons of "all protocols allowed" is vice versa.
> >>
> >>If a list of known protocols is configurable, we can cover both cases,
> >>e.g., an empty list or a list ["ANY"] means all protocols are allowed.
> >>The question in this case is what is the best default value.
> >>
> >>My preference is to allow all protocols. At least a list of known
> >>protocols needs to be configurable.
> >>In my principle, a virtual network should be able to convery any type
> >>of IP protocols in a virtual network. This is the reason of my
> >>preference.
> >>
> >>-----
> >>Regarding (a), if a name and a number refer to a same protocol, it
> >>should be considered as identical.
> >>For example, ip protocol number 6 is "tcp", so ip protocol number 6
> >>and protocol name "tcp" should be regarded as same.
> >>My preference is to allow both name and number of IP protocol. This
> >>will be achieved by Arvind's patch under the review.
> >>"name" representation is easy to understand in general, but
> >>maintaining all protocol names is a tough work.
> >>This is the reason of my preference.
> >>
> >>
> >>I understand there is a topic whether a list of known protocols should
> >>contain name only or accepts both name and number.
> >>I don't discuss it here because it is a simple question once we have a
> >>consensus on the above two topic.
> >>
> >>Thanks,
> >>Akihiro
> >>
> >>On Wed, Sep 11, 2013 at 11:15 PM, Arvind Somya (asomya)
> >><asomya at cisco.com> wrote:
> >>> Hello all
> >>>
> >>> I have a patch in review where  Akihiro made some comments about only
> >>> restricting protocols by names and allowing all protocol numbers when
> >>> creating security group rules. I personally disagree with this approach
> >>>as
> >>> names and numbers are just a textual/integer representation of a common
> >>> protocol. The end result is going to be the same in both cases.
> >>>
> >>> https://review.openstack.org/#/c/43725/
> >>>
> >>> Akihiro suggested a community discussion around this issue before the
> >>>patch
> >>> is accepted upstream. I hope this e-mail gets the ball rolling on that.
> >>>I
> >>> would like to hear the community's opinion on this issue and any
> >>> pros/cons/pitfalls of either approach.
> >>>
> >>> Thanks
> >>> Arvind
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >>--
> >>Akihiro MOTOKI <amotoki at gmail.com>
> >>
> >>_______________________________________________
> >>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
>
> --
> Akihiro MOTOKI <amotoki at gmail.com>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 11 Sep 2013 17:53:48 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] How the autoscale API should
>         control scaling in Heat
> Message-ID: <CE55FA8D.477D7%harlowja at yahoo-inc.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I just have this idea that if u imagine a factory. Heat is the 'robot' in
> an assembly line that ensures the 'assembly line' is done correctly. At
> different stages heat makes sure the 'person/thing' putting a part on does
> it correctly and heat verifies that the part is in the right place (for
> example, nova didn't put the wheel on backwards). The 'robot' then moves
> the partially completed part to the next person and repeats the same
> checks.
>
> So to me, autoscaling say a database would be like going through the
> stages of that assembly line via a non-user triggered system (the
> autoscaler) and then the final 'paint job' on the vms would be done by the
> handoff from heat -> trove. Then trove doesn't need to call back into heat
> to make vms that it uses, heat does this for trove as part of the assembly
> line.
>
> +2 for factory example, ha.
>
> On 9/11/13 9:11 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
>
> >Sure,
> >
> >I was thinking that since heat would do autoscaling persay, then heat
> >would say ask trove to make more databases (autoscale policy here) then
> >this would cause trove to actually callback into heat to make more
> >instances.
> >
> >Just feels a little weird, idk.
> >
> >Why didn't heat just make those instances "on behalf of trove" to begin
> >with and then tell trove "make these instances into databases". Then
> >trove doesn't really need to worry about calling into heat to do the
> >instance creation "work", and trove can just worry about converting those
> >"blank instances " into databases (for example).
> >
> >But maybe I am missing other context also :)
> >
> >Sent from my really tiny device...
> >
> >On Sep 11, 2013, at 8:04 AM, "Clint Byrum" <clint at fewbar.com> wrote:
> >
> >> Excerpts from Joshua Harlow's message of 2013-09-11 01:00:37 -0700:
> >>> +1
> >>>
> >>> The assertions are not just applicable to autoscaling but to software
> >>>in general. I hope we can make autoscaling "just enough" simple to work.
> >>>
> >>> The circular heat<=>trove example is one of those that does worry me a
> >>>little. It feels like something is not structured right if that it is
> >>>needed (rube goldberg like). I am not sure what could be done
> >>>differently, just my gut feeling that something is "off".
> >>
> >> Joshua, can you elaborate on "the circular heat<=>trove example"?
> >>
> >> I don't see Heat and Trove's relationship as circular. Heat has a Trove
> >> resource, and (soon? now?) Trove can use Heat to simplify its control
> >> of underlying systems. This is a stack, not a circle, or did I miss
> >> something?
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 11 Sep 2013 13:05:01 -0500
> From: Dolph Mathews <dolph.mathews at gmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID:
>         <CAC=h7gUiYkyZgsTykGzzve1p2Wk8QmTsdRVhG+FV3qL=
> sUWpiA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick <d.w.chadwick at kent.ac.uk
> >wrote:
>
> > Further supplementary information to Adam's email below, is that there
> are
> > already one further federation protocol profiles that has been published:
> > for an external Keystone acting as an IdP at
> > https://review.openstack.org/#**/c/42107/<
> https://review.openstack.org/#/c/42107/>
> >
> > and another for SAML has been prepared and is ready for publication.
> >
> > I would expect several additional federation profiles to be published in
> > the future, for example, for OpenID Connect and what ever else might be
> > just around the corner.
> >
> > Given the fact that the number of federation protocols is not fixed, and
> > will evolve with time, then I would prefer their method of integration
> into
> > Keystone to be common, so that one "federation" module can handle all the
> > non-protocol specific federation features, such as policy and trust
> > checking, and this module can have multiple different protocol handling
> > modules plugged into it that deal with the protocol specific features
> only.
> > This is the method we have adopted in our current implementation of
> > federation, and have shown that it is a viable and efficient way of
> > implementation as we currently support three protocol profiles (SAML,
> ABFAB
> > and External Keystone).
> >
> > Thus I prefer
> >
> > "method": "federation" "protocol": "abfab"
> >
> > in which the abfab part would be replaced by the particular protocol, and
> > there are common parameters to be used by the federation module
>
>
> > instead of "method": "abfab"
> >
> > as the latter removes the common parameters from federation, and also
> > means that common code wont be used, unless it is cut and paste into each
> > protocol specific module.
> >
>
> That sounds like a pretty strong argument in favor of the current design,
> assuming the "abfab" parameters are children of the common "federation"
> parameters (rather than a sibling of the "federation" parameters)... which
> does appear to be the case the current patchset-
> https://review.openstack.org/#**/c/42221/<
> https://review.openstack.org/#/c/42221/>
>
>
> >
> > Comments?
> >
> > David
> >
> >
> >
> > On 11/09/2013 16:25, Adam Young wrote:
> >
> >> David Chadwick wrote up an in depth API extension for Federation:
> >> https://review.openstack.org/#**/c/39499<
> https://review.openstack.org/#/c/39499>
> >> There is an abfab API proposal as well:
> >> https://review.openstack.org/#**/c/42221/<
> https://review.openstack.org/#/c/42221/>
> >>
> >> After discussing this for a while, it dawned on me that Federation
> >> should not be something bolted on to Keystone, but rather that it was
> >> already central to the design.
> >>
> >> The SQL Identity backend is a simple password store that collects users
> >> into groups.  This makes it an identity provider (IdP).
> >> Now Keystone can register multiple LDAP servers as Identity backends.
> >>
> >> There are requests for SAML and ABFAB integration into Keystone as well.
> >>
> >> Instead of a "Federation API"  Keystone should take the key concepts
> >> from the API and make them core concepts.  What would this mean:
> >>
> >> 1.  Instead of "method": "federation" "protocol": "abfab"  it would be
> >> "method": "abfab",
> >> 2.  The rules about multiple round trips (phase)  would go under the
> >> "abfab" section.
> >> 3.  There would not be a "protocol_data" section but rather that would
> >> be the "abfab" section as well.
> >> 4.  Provider ID would be standard in the method specific section.
> >>
> >> One question that has come up has been about Providers, and whether they
> >> should be considered endpoints in the Catalog.  THere is a couple issues
> >> wiuth this:  one is that they are not something managed by OpenStack,
> >> and two is that they are not necessarily Web Protocols.  As such,
> >> Provider should probably be First class citizen.  We already have LDAP
> >> handled this way, although not as an enumerated entity.  For the first
> >> iteration, I would like to see ABFAB, SAML, and any other protocols we
> >> support done the same way as LDAP:  a deliberate configuration option
> >> for Keystone that will require a config file change.
> >>
> >> David and I have discussed this in a side conversation, and agree that
> >> it requires wider input.
> >>
> >>
> >>
> >>
> >> ______________________________**_________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> >> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >>
> >
> > ______________________________**_________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
>
>
>
> --
>
> -Dolph
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/f6258e2f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Wed, 11 Sep 2013 11:10:39 -0700
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] How the autoscale API should
>         control scaling in Heat
> Message-ID: <1378922787-sup-5852 at fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Joshua Harlow's message of 2013-09-11 09:11:06 -0700:
> > Sure,
> >
> > I was thinking that since heat would do autoscaling persay, then heat
> would say ask trove to make more databases (autoscale policy here) then
> this would cause trove to actually callback into heat to make more
> instances.
> >
> > Just feels a little weird, idk.
> >
> > Why didn't heat just make those instances "on behalf of trove" to begin
> with and then tell trove "make these instances into databases". Then trove
> doesn't really need to worry about calling into heat to do the instance
> creation "work", and trove can just worry about converting those "blank
> instances " into databases (for example).
> >
> > But maybe I am missing other context also :)
> >
>
> That sort of optimization would violate encapsulation and make the system
> more complex.
>
> Heat doing Trove's provisioning and coordinating Trove's interaction with
> other pieces of the system is an implementation detail, safely hidden
> behind Trove. Interaction between other pieces of the end user's stack
> and Trove is limited to what Trove wants to expose.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 11 Sep 2013 14:26:36 -0400
> From: Doug Hellmann <doug.hellmann at dreamhost.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Ceilometer] Correct way to disable
>         specific event collection by the collector
> Message-ID:
>         <
> CADb+p3S81eRKc_ZonU7eVkDUbORBWj-E_hP_rRCHEBMVJsNVMA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> You can configure the collector's pipeline to only listen to certain
> events, but you shouldn't need to worry about which plugins it actually
> loads. See etc/pipeline.yaml in the source tree for an example file. I
> don't see any docs for that file, but I might be looking in the wrong
> place. If you add the meters you want to the "meters" list, replacing the
> "*", then ceilometer should only collect data for the meters you care
> about.
>
>
> On Wed, Sep 11, 2013 at 12:17 PM, Neal, Phil <phil.neal at hp.com> wrote:
>
> > Greetings team,
> > I'm working on getting a very streamlined set of collections running and
> > I'd like to disable all notifications except Glance. It's clear that the
> > desired event types are defined in the plugins, but I can't seem to work
> > out how to force the collector service to load only specific handlers in
> > the "ceilometer.collector" namespace. I *thought* it could be
> accomplished
> > by editing /ceilometer/setup.cfg, but removing the entry points there
> > didn't seem to work (the extensions manager still picks them up).
> >
> > Can someone give me a rough idea of how to do this?
> >
> > - Phil
> >
> >
> > _______________________________________________
> > 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/20130911/befb779c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 11
> Date: Wed, 11 Sep 2013 14:35:37 -0400
> From: Brad Topol <btopol at us.ibm.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID:
>         <
> OFEE7D4E3E.98BEF8A5-ON85257BE3.0062A4B5-85257BE3.006622E8 at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Adam,
>
> One thing I think we should capture before going deep into design and
> implementation is to understand the federated identity use cases that our
> stakeholders need us to support. I'm hoping we all can start capturing
> these in a federated identity icehouse design summit session.
>
> Thanks,
>
> Brad
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet:  btopol at us.ibm.com
> Assistant: Cindy Willman (919) 268-5296
>
>
>
> From:   Adam Young <ayoung at redhat.com>
> To:     OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Date:   09/11/2013 11:28 AM
> Subject:        [openstack-dev] Keystone and Multiple Identity Sources
>
>
>
> David Chadwick wrote up an in depth API extension for Federation:
> https://review.openstack.org/#/c/39499
> There is an abfab API proposal as well:
> https://review.openstack.org/#/c/42221/
>
> After discussing this for a while, it dawned on me that Federation
> should not be something bolted on to Keystone, but rather that it was
> already central to the design.
>
> The SQL Identity backend is a simple password store that collects users
> into groups.  This makes it an identity provider (IdP).
> Now Keystone can register multiple LDAP servers as Identity backends.
>
> There are requests for SAML and ABFAB integration into Keystone as well.
>
> Instead of a "Federation API"  Keystone should take the key concepts
> from the API and make them core concepts.  What would this mean:
>
> 1.  Instead of "method": "federation" "protocol": "abfab"  it would be
> "method": "abfab",
> 2.  The rules about multiple round trips (phase)  would go under the
> "abfab" section.
> 3.  There would not be a "protocol_data" section but rather that would
> be the "abfab" section as well.
> 4.  Provider ID would be standard in the method specific section.
>
> One question that has come up has been about Providers, and whether they
> should be considered endpoints in the Catalog.  THere is a couple issues
> wiuth this:  one is that they are not something managed by OpenStack,
> and two is that they are not necessarily Web Protocols.  As such,
> Provider should probably be First class citizen.  We already have LDAP
> handled this way, although not as an enumerated entity.  For the first
> iteration, I would like to see ABFAB, SAML, and any other protocols we
> support done the same way as LDAP:  a deliberate configuration option
> for Keystone that will require a config file change.
>
> David and I have discussed this in a side conversation, and agree that
> it requires wider input.
>
>
>
>
> _______________________________________________
> 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/20130911/4295291b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Wed, 11 Sep 2013 14:59:53 -0400
> From: Mike Spreitzer <mspreitz at us.ibm.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] Comments/questions on the
>         instance-group-api-extension blueprint
> Message-ID:
>         <
> OF06A2A5CB.81E62F0B-ON85257BE3.0067875C-85257BE3.00685C68 at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Yes, I've seen that material.  In my group we have worked larger and more
> complex examples.  I have a proposed breakout session at the Hong Kong
> summit to talk about one, you might want to vote for it.  The URL is
>
> http://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/109
> and the title is "Continuous Delivery of Lotus Connections on OpenStack".
> We used our own technology to do the scheduling (make placement decisions)
> and orchestration, calling Nova and Quantum to carry out the decisions our
> software made.  Above the OpenStack infrastructure we used two layers of
> our own software, one focused on infrastructure and one adding concerns
> for the software running on that infrastructure.  Each used its own
> language for a whole topology AKA pattern AKA application AKA cluster. For
> example, our pattern has 16 VMs running the WebSphere application server,
> organized into four homogenous groups (members are interchangeable) of
> four each.  For each group, we asked that it both (a) be spread across at
> least two racks, with no more than half the VMs on any one rack and (b)
> have no two VMs on the same hypervisor.  You can imagine how this would
> involve multiple levels of grouping and relationships between groups (and
> you will probably be surprised by the particulars).  We also included
> information on licensed products, so that the placement decision can
> optimize license cost (for the IBM "sub-capacity" licenses, placement of
> VMs can make a cost difference).  Thus, multiple policies per thing.  We
> are now extending that example to include storage, and we are also working
> examples with Hadoop.
>
> Regards,
> Mike
>
>
>
> From:   Gary Kotton <gkotton at vmware.com>
> To:     OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>,
> Date:   09/11/2013 06:06 AM
> Subject:        Re: [openstack-dev] [heat] Comments/questions on the
> instance-group-api-extension blueprint
>
>
>
>
>
> From: Mike Spreitzer <mspreitz at us.ibm.com>
> Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, September 10, 2013 11:58 PM
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [heat] Comments/questions on the
> instance-group-api-extension blueprint
>
> First, I'm a newbie here, wondering: is this the right place for
> comments/questions on blueprints?  Supposing it is...
>
> [Gary Kotton] Yeah, as Russel said this is the correct place
>
> I am referring to
> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
>
> In my own research group we have experience with a few systems that do
> something like that, and more (as, indeed, that blueprint explicitly
> states that it is only the start of a longer roadmap).  I would like to
> highlight a couple of differences that alarm me.  One is the general
> overlap between groups.  I am not saying this is wrong, but as a matter of
> natural conservatism we have shied away from unnecessary complexities. The
> only overlap we have done so far is hierarchical nesting.  As the
> instance-group-api-extension explicitly contemplates groups of groups as a
> later development, this would cover the overlap that we have needed.  On
> the other hand, we already have multiple "policies" attached to a single
> group.  We have policies for a variety of concerns, so some can combine
> completely or somewhat independently.  We also have relationships (of
> various sorts) between groups (as well as between individuals, and between
> individuals and groups).  The policies and relationships, in general, are
> not simply names but also have parameters.
>
> [Gary Kotton] The instance groups was meant to be the first step towards
> what we had presented in Portland. Please look at the presentation that we
> gave an this may highlight what the aims were:
>
> https://docs.google.com/presentation/d/1oDXEab2mjxtY-cvufQ8f4cOHM0vIp4iMyfvZPqg8Ivc/edit?usp=sharing
> . Sadly for this release we did not manage to get the instance groups
> through (it was an issue of timing and bad luck). We will hopefully get
> this though in the first stages of the I cycle and then carry on building
> on it as it has a huge amount of value for OpenStack. It will be great if
> you can also participate in the discussions.
>
> Thanks,
> Mike_______________________________________________
> 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/20130911/664be013/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Wed, 11 Sep 2013 20:03:30 +0100
> From: David Chadwick <d.w.chadwick at kent.ac.uk>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID: <5230BE82.5020609 at kent.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> On 11/09/2013 19:05, Dolph Mathews wrote:
> >
> > On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick
> > <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
> >
> >     Further supplementary information to Adam's email below, is that
> >     there are already one further federation protocol profiles that has
> >     been published:
> >     for an external Keystone acting as an IdP at
> >     https://review.openstack.org/#__/c/42107/
> >     <https://review.openstack.org/#/c/42107/>
> >
> >     and another for SAML has been prepared and is ready for publication.
> >
> >     I would expect several additional federation profiles to be
> >     published in the future, for example, for OpenID Connect and what
> >     ever else might be just around the corner.
> >
> >     Given the fact that the number of federation protocols is not fixed,
> >     and will evolve with time, then I would prefer their method of
> >     integration into Keystone to be common, so that one "federation"
> >     module can handle all the non-protocol specific federation features,
> >     such as policy and trust checking, and this module can have multiple
> >     different protocol handling modules plugged into it that deal with
> >     the protocol specific features only. This is the method we have
> >     adopted in our current implementation of federation, and have shown
> >     that it is a viable and efficient way of implementation as we
> >     currently support three protocol profiles (SAML, ABFAB and External
> >     Keystone).
> >
> >     Thus I prefer
> >
> >     "method": "federation" "protocol": "abfab"
> >
> >     in which the abfab part would be replaced by the particular
> >     protocol, and there are common parameters to be used by the
> >     federation module
> >
> >
> >     instead of "method": "abfab"
> >
> >     as the latter removes the common parameters from federation, and
> >     also means that common code wont be used, unless it is cut and paste
> >     into each protocol specific module.
> >
> >
> > That sounds like a pretty strong argument in favor of the current
> > design, assuming the "abfab" parameters are children of the common
> > "federation" parameters (rather than a sibling of the "federation"
> > parameters)... which does appear to be the case the current patchset-
> > https://review.openstack.org/#__/c/42221/
> > <https://review.openstack.org/#/c/42221/>
>
> this would require protocol_data to become a child of the other three
> parameters, which can easily be done. The protocol_data is an array of
> any parameters that the protocol specific code wants to put in there.
> The protocol specific profile document specifies what these are.
>
> regards
>
> David
>
>
> >
> >
> >     Comments?
> >
> >     David
> >
> >
> >
> >     On 11/09/2013 16:25, Adam Young wrote:
> >
> >         David Chadwick wrote up an in depth API extension for Federation:
> >         https://review.openstack.org/#__/c/39499
> >         <https://review.openstack.org/#/c/39499>
> >         There is an abfab API proposal as well:
> >         https://review.openstack.org/#__/c/42221/
> >         <https://review.openstack.org/#/c/42221/>
> >
> >         After discussing this for a while, it dawned on me that
> Federation
> >         should not be something bolted on to Keystone, but rather that
> >         it was
> >         already central to the design.
> >
> >         The SQL Identity backend is a simple password store that
> >         collects users
> >         into groups.  This makes it an identity provider (IdP).
> >         Now Keystone can register multiple LDAP servers as Identity
> >         backends.
> >
> >         There are requests for SAML and ABFAB integration into Keystone
> >         as well.
> >
> >         Instead of a "Federation API"  Keystone should take the key
> concepts
> >         from the API and make them core concepts.  What would this mean:
> >
> >         1.  Instead of "method": "federation" "protocol": "abfab"  it
> >         would be
> >         "method": "abfab",
> >         2.  The rules about multiple round trips (phase)  would go under
> the
> >         "abfab" section.
> >         3.  There would not be a "protocol_data" section but rather that
> >         would
> >         be the "abfab" section as well.
> >         4.  Provider ID would be standard in the method specific section.
> >
> >         One question that has come up has been about Providers, and
> >         whether they
> >         should be considered endpoints in the Catalog.  THere is a
> >         couple issues
> >         wiuth this:  one is that they are not something managed by
> >         OpenStack,
> >         and two is that they are not necessarily Web Protocols.  As such,
> >         Provider should probably be First class citizen.  We already
> >         have LDAP
> >         handled this way, although not as an enumerated entity.  For the
> >         first
> >         iteration, I would like to see ABFAB, SAML, and any other
> >         protocols we
> >         support done the same way as LDAP:  a deliberate configuration
> >         option
> >         for Keystone that will require a config file change.
> >
> >         David and I have discussed this in a side conversation, and
> >         agree that
> >         it requires wider input.
> >
> >
> >
> >
> >         _________________________________________________
> >         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
> >         <
> 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 <
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
> >
> >
> >
> > --
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 11 Sep 2013 19:06:52 +0000
> From: Justin Hammond <justin.hammond at RACKSPACE.COM>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Need some clarity on security
>         group protocol numbers vs names
> Message-ID: <CE56295E.E3B3%justin.hammond at rackspace.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I agree with you. Plugin was a mere example and it does make sense to
> allow the provider to define custom protocols.
>
> +1
>
> On 9/11/13 12:46 PM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
>
> >Hi Justin,
> >
> >My point is what
> >
> >On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond
> ><justin.hammond at rackspace.com> wrote:
> >> As it seems the review is no longer the place for this discussion, I
> >>will
> >> copy/paste my inline comments here:
> >>
> >> I dislike the idea of passing magical numbers around to define protocols
> >> (defined or otherwise). I believe there should be a common set of
> >> protocols with their numbers mapped (such as this constants business)
> >>and
> >> a well defined way to validate/list said common constants.
> >
> >I agree that value should be validated appropriately in general.
> >A configurable list of allowed protocols looks good to me.
> >
> >> wishes to add support for a protocol outside of the common case, it
> >>should
> >> be added to the list in a pluggable manner.
> >> Ex: common defines the constants 1, 6, 17 to be valid but my_cool_plugin
> >> wants to support 42. It should be my plugin's responsibility to add 42
> >>to
> >> the list of valid protocols by appending to the list given a pluggable
> >> interface to do so. I do not believe plugins should continue to update
> >>the
> >> common.constants file with new protocols, but I do believe explicitly
> >> stating which protocols are valid is better than allowing users to
> >> possibly submit protocols erroneously.
> >
> >I think this is just a case a backend plugin defines allowed protocols.
> >
> >I also see a different case: a cloud provider defines allowed protocols.
> >For example VLAN network type of OVS plugin can convey any type of packets
> >including GRE, STCP and so on if a provider wants to do so.
> >We need to allow a provider to configure the list.
> >
> >Considering the above, what we need to do looks:
> >(a) to validate values properly,
> >(b) to allow a plugin to define what protocols should be allowed
> >    (I think we need two types of lists: possible protocols and
> >default allowed protocols)
> >(c) to allow a cloud provider (deployer) to customize allow protocols.
> >    (Of course (c) is a subnet of "possible protocols" in (b))
> >
> >Does it make sense?
> >The above is just a start point of the discussion and some list can be
> >omitted.
> >
> ># Whether (c) is needed or not depends on the default list of (b).
> ># If it is wide enough (c) is not needed. The current list of (b) is
> >[tcp, udp, icmp]
> ># and it looks too small set to me, so it is better to have (c) too.
> >
> >> If the plugins use a system such as this, it is possible that new,
> >>common,
> >> protocols can be found to be core. See NETWORK_TYPE constants.
> >
> >I think the situation is a bit different. What network types are
> >allowed is tightly
> >coupled with a plugin implementation, and a cloud provider choose a plugin
> >based on their needs. Thus the mechanism of NETWORK_TYPE constants
> >make sense to me too.
> >
> >> tl;dr: magic constants are no good, but values should be validated in a
> >> pluggable and explicit manner.
> >
> >As I said above, I agree it is important to validate values properly in
> >general.
> >
> >Thanks,
> >Akihiro
> >
> >>
> >>
> >>
> >> On 9/11/13 10:40 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
> >>
> >>>Hi all,
> >>>
> >>>Arvind, thank you for initiate the discussion about the ip protocol in
> >>>security group rules.
> >>>I think the discussion point can be broken down into:
> >>>
> >>>(a) how to specify ip protocol : by name, number, or both
> >>>(b) what ip protocols can be specified: known protocols only, all
> >>>protocols (or some subset of protocols including unknown protocols)
> >>>     where "known protocols" is defined as a list in Neutron (a list
> >>>of constants or a configurable list)
> >>>
> >>>------
> >>>(b) is the main topic Arvind and I discussed in the review.
> >>>If only known protocols are allowed, we cannot allow protocols which
> >>>are not listed in the known protocol list.
> >>>For instance, if "tcp", "udp" and "icmp" are registered as known
> >>>protocols (this is the current neutron implementation),
> >>>a tenant cannot allow "stcp" or "gre".
> >>>
> >>>Pros of "known protocols only" is the infrastructure provider can
> >>>control which protocols are allowed.
> >>>Cons is that users cannot use ip protocols not listed in a known list
> >>>and a provider needs to maintain a known protocol list.
> >>>Pros and cons of "all protocols allowed" is vice versa.
> >>>
> >>>If a list of known protocols is configurable, we can cover both cases,
> >>>e.g., an empty list or a list ["ANY"] means all protocols are allowed.
> >>>The question in this case is what is the best default value.
> >>>
> >>>My preference is to allow all protocols. At least a list of known
> >>>protocols needs to be configurable.
> >>>In my principle, a virtual network should be able to convery any type
> >>>of IP protocols in a virtual network. This is the reason of my
> >>>preference.
> >>>
> >>>-----
> >>>Regarding (a), if a name and a number refer to a same protocol, it
> >>>should be considered as identical.
> >>>For example, ip protocol number 6 is "tcp", so ip protocol number 6
> >>>and protocol name "tcp" should be regarded as same.
> >>>My preference is to allow both name and number of IP protocol. This
> >>>will be achieved by Arvind's patch under the review.
> >>>"name" representation is easy to understand in general, but
> >>>maintaining all protocol names is a tough work.
> >>>This is the reason of my preference.
> >>>
> >>>
> >>>I understand there is a topic whether a list of known protocols should
> >>>contain name only or accepts both name and number.
> >>>I don't discuss it here because it is a simple question once we have a
> >>>consensus on the above two topic.
> >>>
> >>>Thanks,
> >>>Akihiro
> >>>
> >>>On Wed, Sep 11, 2013 at 11:15 PM, Arvind Somya (asomya)
> >>><asomya at cisco.com> wrote:
> >>>> Hello all
> >>>>
> >>>> I have a patch in review where  Akihiro made some comments about only
> >>>> restricting protocols by names and allowing all protocol numbers when
> >>>> creating security group rules. I personally disagree with this
> >>>>approach
> >>>>as
> >>>> names and numbers are just a textual/integer representation of a
> >>>>common
> >>>> protocol. The end result is going to be the same in both cases.
> >>>>
> >>>> https://review.openstack.org/#/c/43725/
> >>>>
> >>>> Akihiro suggested a community discussion around this issue before the
> >>>>patch
> >>>> is accepted upstream. I hope this e-mail gets the ball rolling on
> >>>>that.
> >>>>I
> >>>> would like to hear the community's opinion on this issue and any
> >>>> pros/cons/pitfalls of either approach.
> >>>>
> >>>> Thanks
> >>>> Arvind
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>Akihiro MOTOKI <amotoki at gmail.com>
> >>>
> >>>_______________________________________________
> >>>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
> >
> >--
> >Akihiro MOTOKI <amotoki at gmail.com>
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Thu, 12 Sep 2013 00:16:18 +0400
> From: Sergey Lukjanov <slukjanov at mirantis.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>, OpenStack TC Mailing List
> Mailing
>         List <openstack-tc at lists.openstack.org>
> Subject: [openstack-dev] TC Meeting / Savanna Incubation Follow-Up
> Message-ID: <A257976C-DCA4-4B58-B3E3-A249FFB1CC3A at mirantis.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hi folks,
>
> Initial discussions of Savanna Incubation request have been started
> yesterday. Two major topics being discussed were Heat integration and
> ?clustering library? [1].
>
> To start with let me give a brief overview of key Savanna features:
> 1. Provisioning of underlying OpenStack resources (like compute, volume,
> network) required for Hadoop cluster.
> 2. Hadoop cluster deployment and configuration.
> 3. Integration with different Hadoop distributions through plugin
> mechanism with single control plan for all of them. In future can be used
> to integrate with other Data Processing frameworks, for example, Twitter
> Storm.
> 4. Reliability and performance optimizations to ensure Hadoop cluster
> performance on top of OpenStack, like enabling Swift to be used as
> underlying HDFS and exposing information on Swift data locality to Hadoop
> scheduler.
> 5. Set of Elastic Data Processing features:
>   * Hadoop jobs on-demand execution
>   * Pool of different external data sources, like Swift, external Hadoop
> cluster, NoSQL and traditional databases
>   * Pig and Hive integration
> 6. OpenStack Dashboard plugin for all above.
>
> I highly recommend to view our screencast about Savanna 0.2 release (mid
> July) [2] to better understand Savanna functionality.
>
> As you can see, resources provisioning is just one of the features and the
> implementation details are not critical for overall architecture. It
> performs only the first step of the cluster setup. We?ve been considering
> Heat for a while, but ended up direct API calls in favor of speed and
> simplicity. Going forward Heat integration will be done by implementing
> extension mechanism [3] and [4] as part of Icehouse release.
>
> The next part, Hadoop cluster configuration, already extensible and we
> have several plugins - Vanilla, Hortonworks Data Platform and Cloudera
> plugin started too. This allow to unify management of different Hadoop
> distributions under single control plane. The plugins are responsible for
> correct Hadoop ecosystem configuration at already provisioned resources and
> use different Hadoop management tools like Ambari to setup and configure
> all cluster  services, so, there are no actual provisioning configs on
> Savanna side in this case. Savanna and its plugins encapsulate the
> knowledge of Hadoop internals and default configuration for Hadoop services.
>
>
>
> The next topic is ?Cluster API?.
>
> The concern that was raised is how to extract general clustering
> functionality to the common library. Cluster provisioning and management
> topic currently relevant for a number of projects within OpenStack
> ecosystem: Savanna, Trove, TripleO, Heat, Taskflow.
>
> Still each of the projects has their own understanding of what the cluster
> provisioning is. The idea of extracting common functionality sounds
> reasonable, but details still need to be worked out.
>
> I?ll try to highlight Savanna team current perspective on this question.
> Notion of ?Cluster management? in my perspective has several levels:
> 1. Resources provisioning and configuration (like instances, networks,
> storages). Heat is the main tool with possibly additional support from
> underlying services. For example, instance grouping API extension [5] in
> Nova would be very useful.
> 2. Distributed communication/task execution. There is a project in
> OpenStack ecosystem with the mission to provide a framework for distributed
> task execution - TaskFlow [6]. It?s been started quite recently. In Savanna
> we are really looking forward to use more and more of its functionality in
> I and J cycles as TaskFlow itself getting more mature.
> 3. Higher level clustering - management of the actual services working on
> top of the infrastructure. For example, in Savanna configuring HDFS data
> nodes or in Trove setting up MySQL cluster with Percona or Galera. This
> operations are typical very specific for the project domain. As for Savanna
> specifically, we use lots of benefits of Hadoop internals knowledge to
> deploy and configure it properly.
>
> Overall conclusion it seems to be that it make sense to enhance Heat
> capabilities and invest in Taskflow development, leaving domain-specific
> operations to the individual projects.
>
> I also would like to emphasize that in Savanna Hadoop cluster management
> is already implemented including scaling support.
>
> With all this I do believe Savanna fills an important gap in OpenStack by
> providing Data Processing capabilities in cloud environment in general and
> integration with Hadoop ecosystem as the first particular step.
>
> Hadoop ecosystem on its own is huge and integration will add significant
> value to OpenStack community and users [7].
>
>
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-09-10-20.02.log.html
> [2] http://www.youtube.com/watch?v=SrlHM0-q5zI
> [3]
> https://blueprints.launchpad.net/savanna/+spec/infra-provisioning-extensions
> [4]
> https://blueprints.launchpad.net/savanna/+spec/heat-backed-resources-provisioning
> [5]
> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
> [6] https://launchpad.net/taskflow
> [7]
> http://www.google.com/trends/explore?q=openstack%2Chadoop#q=openstack%2C%20hadoop&cmpt=q
>
> Sincerely yours,
> Sergey Lukjanov
> Savanna Technical Lead
> Mirantis Inc.
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 11 Sep 2013 16:32:11 -0400
> From: Sean Dague <sean at dague.net>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [qa] nominations for tempest-core
> Message-ID: <5230D34B.9040905 at dague.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> We're in Feature Freeze for the Open Stack projects, which actually
> means we're starting the busy cycle for Tempest in people landing
> additional tests for verification of features that hadn't gone in until
> recently. As such, I think now is a good time to consider some new core
> members. There are two people I think have been doing an exceptional job
> that we should include in the core group
>
> Mark Koderer has been spear heading the stress testing in Tempest,
> completing the new stress testing for the H3 milestone, and has gotten
> very active in reviews over the last three months.
>
> You can see his contributions here:
>
> https://review.openstack.org/#/q/project:openstack/tempest+owner:m.koderer%2540telekom.de,n,z
>
> And his code reviews here: his reviews here -
>
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:m.koderer%2540telekom.de,n,z
>
>
> Giulio Fidente did a lot of great work bringing our volumes testing up
> to par early in the cycle, and has been very active in reviews since the
> Havana cycle opened up.
>
> You can see his contributions here:
>
> https://review.openstack.org/#/q/project:openstack/tempest+owner:gfidente%2540redhat.com,n,z
>
> And his code reviews here: his reviews here -
>
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:gfidente%2540redhat.com,n,z
>
>
> Both have been active in blueprints and the openstack-qa meetings all
> summer long, and I think would make excellent additions to the Tempest
> core team.
>
> Current QA core members, please vote +1 or -1 to these nominations when
> you get a chance. We'll keep the polls open for 5 days or until everyone
> has voiced their votes.
>
> For reference here are the 90 day review stats for Tempest as of today:
>
> Reviews for the last 90 days in tempest
> ** -- tempest-core team member
> +----------------------+-----------------------------------+
> |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |
> +----------------------+-----------------------------------+
> |     afazekas **      |     275 (1|29|18|227) (89.1%)     |
> |      sdague **       |      198 (4|60|0|134) (67.7%)     |
> |       gfidente       |      130 (0|55|75|0) (57.7%)      |
> |    david-kranz **    |      112 (1|24|0|87) (77.7%)      |
> |     treinish **      |      109 (5|32|0|72) (66.1%)      |
> |      cyeoh-0 **      |       87 (0|19|4|64) (78.2%)      |
> |       mkoderer       |       69 (0|20|49|0) (71.0%)      |
> |     jaypipes **      |       65 (0|22|0|43) (66.2%)      |
> |        igawa         |       49 (0|10|39|0) (79.6%)      |
> |       oomichi        |       30 (0|9|21|0) (70.0%)       |
> |         jogo         |       26 (0|12|14|0) (53.8%)      |
> |       adalbas        |       22 (0|4|18|0) (81.8%)       |
> | ravikumar-venkatesan |       22 (0|2|20|0) (90.9%)       |
> |       ivan-zhu       |       21 (0|10|11|0) (52.4%)      |
> |       mriedem        |        13 (0|4|9|0) (69.2%)       |
> |   andrea-frittoli    |        12 (0|4|8|0) (66.7%)       |
> |       mkollaro       |        10 (0|5|5|0) (50.0%)       |
> |      zhikunliu       |        10 (0|4|6|0) (60.0%)       |
> |        Anju5         |        9 (0|0|9|0) (100.0%)       |
> |       anteaya        |        7 (0|3|4|0) (57.1%)        |
> |         Anju         |        7 (0|0|7|0) (100.0%)       |
> |   steve-stevebaker   |        6 (0|3|3|0) (50.0%)        |
> |       prekarat       |        5 (0|3|2|0) (40.0%)        |
> |        rahmu         |        5 (0|2|3|0) (60.0%)        |
> |       psedlak        |        4 (0|3|1|0) (25.0%)        |
> |        minsel        |        4 (0|3|1|0) (25.0%)        |
> |    zhiteng-huang     |        3 (0|2|1|0) (33.3%)        |
> |         maru         |        3 (0|1|2|0) (66.7%)        |
> |       iwienand       |        3 (0|1|2|0) (66.7%)        |
> |    FujiokaYuuichi    |        3 (0|1|2|0) (66.7%)        |
> |        dolph         |        3 (0|0|3|0) (100.0%)       |
> |     cthiel-suse      |        3 (0|0|3|0) (100.0%)       |
> |    walter-boring     |         2 (0|2|0|0) (0.0%)        |
> |        bnemec        |         2 (0|2|0|0) (0.0%)        |
> |       lifeless       |        2 (0|1|1|0) (50.0%)        |
> |    fabien-boucher    |        2 (0|1|1|0) (50.0%)        |
> |     alex_gaynor      |        2 (0|1|1|0) (50.0%)        |
> |        alaski        |        2 (0|1|1|0) (50.0%)        |
> |       krtaylor       |        2 (0|0|2|0) (100.0%)       |
> |       cbehrens       |        2 (0|0|2|0) (100.0%)       |
> |       Sumanth        |        2 (0|0|2|0) (100.0%)       |
> |         ttx          |         1 (0|1|0|0) (0.0%)        |
> |       rvaknin        |         1 (0|1|0|0) (0.0%)        |
> |     rohitkarajgi     |         1 (0|1|0|0) (0.0%)        |
> |       ndipanov       |         1 (0|1|0|0) (0.0%)        |
> |   michaeltchapman    |         1 (0|1|0|0) (0.0%)        |
> |       maurosr        |         1 (0|1|0|0) (0.0%)        |
> |      mate-lakat      |         1 (0|1|0|0) (0.0%)        |
> |       jecarey        |         1 (0|1|0|0) (0.0%)        |
> |         jdc          |         1 (0|1|0|0) (0.0%)        |
> |      hartsocks       |         1 (0|1|0|0) (0.0%)        |
> |        flwang        |         1 (0|1|0|0) (0.0%)        |
> |      dscannell       |         1 (0|1|0|0) (0.0%)        |
> |        blk-u         |         1 (0|1|0|0) (0.0%)        |
> |       JordanP        |         1 (0|1|0|0) (0.0%)        |
> |       zhhuabj        |        1 (0|0|1|0) (100.0%)       |
> |       zhaoqin        |        1 (0|0|1|0) (100.0%)       |
> |      yoshimatsu      |        1 (0|0|1|0) (100.0%)       |
> |      vsergeyev       |        1 (0|0|1|0) (100.0%)       |
> |       unknown        |        1 (0|0|1|0) (100.0%)       |
> |        tmello        |        1 (0|0|1|0) (100.0%)       |
> |       tkammer        |        1 (0|0|1|0) (100.0%)       |
> |      thang.pham      |        1 (0|0|1|0) (100.0%)       |
> |    syerrapragada     |        1 (0|0|1|0) (100.0%)       |
> |        swann         |        1 (0|0|1|0) (100.0%)       |
> |        sthaha        |        1 (0|0|1|0) (100.0%)       |
> |        sileht        |        1 (0|0|1|0) (100.0%)       |
> |         seif         |        1 (0|0|1|0) (100.0%)       |
> |       saurabh        |        1 (0|0|1|0) (100.0%)       |
> |        novel         |        1 (0|0|1|0) (100.0%)       |
> |       mpavlase       |        1 (0|0|1|0) (100.0%)       |
> |       mapleoin       |        1 (0|0|1|0) (100.0%)       |
> |       kadachi        |        1 (0|0|1|0) (100.0%)       |
> |     johngarbutt      |        1 (0|0|1|0) (100.0%)       |
> |    john-griffith     |        1 (0|0|1|0) (100.0%)       |
> |    jerome-gallard    |        1 (0|0|1|0) (100.0%)       |
> |       jdanjou        |        1 (0|0|1|0) (100.0%)       |
> |       guochbo        |        1 (0|0|1|0) (100.0%)       |
> |        danms         |        1 (0|0|1|0) (100.0%)       |
> |       cboylan        |        1 (0|0|1|0) (100.0%)       |
> |       asalkeld       |        1 (0|0|1|0) (100.0%)       |
> |        arosen        |        1 (0|0|1|0) (100.0%)       |
> |  armando-migliaccio  |        1 (0|0|1|0) (100.0%)       |
> |         alla         |        1 (0|0|1|0) (100.0%)       |
> |      aji-zqfan       |        1 (0|0|1|0) (100.0%)       |
> |        Liang         |        1 (0|0|1|0) (100.0%)       |
> +----------------------+-----------------------------------+
>
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 11 Sep 2013 16:37:40 -0400
> From: Matthew Treinish <mtreinish at kortar.org>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [qa] nominations for tempest-core
> Message-ID: <20130911203740.GA22478 at kortar.treinish>
> Content-Type: text/plain; charset=us-ascii
>
> +1 for both of them. They've both done great work.
>
> -Matt Treinish
>
> On Wed, Sep 11, 2013 at 04:32:11PM -0400, Sean Dague wrote:
> > We're in Feature Freeze for the Open Stack projects, which actually
> > means we're starting the busy cycle for Tempest in people landing
> > additional tests for verification of features that hadn't gone in
> > until recently. As such, I think now is a good time to consider some
> > new core members. There are two people I think have been doing an
> > exceptional job that we should include in the core group
> >
> > Mark Koderer has been spear heading the stress testing in Tempest,
> > completing the new stress testing for the H3 milestone, and has
> > gotten very active in reviews over the last three months.
> >
> > You can see his contributions here:
> https://review.openstack.org/#/q/project:openstack/tempest+owner:m.koderer%2540telekom.de,n,z
> >
> > And his code reviews here: his reviews here -
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:m.koderer%2540telekom.de,n,z
> >
> >
> > Giulio Fidente did a lot of great work bringing our volumes testing
> > up to par early in the cycle, and has been very active in reviews
> > since the Havana cycle opened up.
> >
> > You can see his contributions here:
> https://review.openstack.org/#/q/project:openstack/tempest+owner:gfidente%2540redhat.com,n,z
> >
> > And his code reviews here: his reviews here -
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:gfidente%2540redhat.com,n,z
> >
> >
> > Both have been active in blueprints and the openstack-qa meetings
> > all summer long, and I think would make excellent additions to the
> > Tempest core team.
> >
> > Current QA core members, please vote +1 or -1 to these nominations
> > when you get a chance. We'll keep the polls open for 5 days or until
> > everyone has voiced their votes.
> >
> > For reference here are the 90 day review stats for Tempest as of today:
> >
> > Reviews for the last 90 days in tempest
> > ** -- tempest-core team member
> > +----------------------+-----------------------------------+
> > |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |
> > +----------------------+-----------------------------------+
> > |     afazekas **      |     275 (1|29|18|227) (89.1%)     |
> > |      sdague **       |      198 (4|60|0|134) (67.7%)     |
> > |       gfidente       |      130 (0|55|75|0) (57.7%)      |
> > |    david-kranz **    |      112 (1|24|0|87) (77.7%)      |
> > |     treinish **      |      109 (5|32|0|72) (66.1%)      |
> > |      cyeoh-0 **      |       87 (0|19|4|64) (78.2%)      |
> > |       mkoderer       |       69 (0|20|49|0) (71.0%)      |
> > |     jaypipes **      |       65 (0|22|0|43) (66.2%)      |
> > |        igawa         |       49 (0|10|39|0) (79.6%)      |
> > |       oomichi        |       30 (0|9|21|0) (70.0%)       |
> > |         jogo         |       26 (0|12|14|0) (53.8%)      |
> > |       adalbas        |       22 (0|4|18|0) (81.8%)       |
> > | ravikumar-venkatesan |       22 (0|2|20|0) (90.9%)       |
> > |       ivan-zhu       |       21 (0|10|11|0) (52.4%)      |
> > |       mriedem        |        13 (0|4|9|0) (69.2%)       |
> > |   andrea-frittoli    |        12 (0|4|8|0) (66.7%)       |
> > |       mkollaro       |        10 (0|5|5|0) (50.0%)       |
> > |      zhikunliu       |        10 (0|4|6|0) (60.0%)       |
> > |        Anju5         |        9 (0|0|9|0) (100.0%)       |
> > |       anteaya        |        7 (0|3|4|0) (57.1%)        |
> > |         Anju         |        7 (0|0|7|0) (100.0%)       |
> > |   steve-stevebaker   |        6 (0|3|3|0) (50.0%)        |
> > |       prekarat       |        5 (0|3|2|0) (40.0%)        |
> > |        rahmu         |        5 (0|2|3|0) (60.0%)        |
> > |       psedlak        |        4 (0|3|1|0) (25.0%)        |
> > |        minsel        |        4 (0|3|1|0) (25.0%)        |
> > |    zhiteng-huang     |        3 (0|2|1|0) (33.3%)        |
> > |         maru         |        3 (0|1|2|0) (66.7%)        |
> > |       iwienand       |        3 (0|1|2|0) (66.7%)        |
> > |    FujiokaYuuichi    |        3 (0|1|2|0) (66.7%)        |
> > |        dolph         |        3 (0|0|3|0) (100.0%)       |
> > |     cthiel-suse      |        3 (0|0|3|0) (100.0%)       |
> > |    walter-boring     |         2 (0|2|0|0) (0.0%)        |
> > |        bnemec        |         2 (0|2|0|0) (0.0%)        |
> > |       lifeless       |        2 (0|1|1|0) (50.0%)        |
> > |    fabien-boucher    |        2 (0|1|1|0) (50.0%)        |
> > |     alex_gaynor      |        2 (0|1|1|0) (50.0%)        |
> > |        alaski        |        2 (0|1|1|0) (50.0%)        |
> > |       krtaylor       |        2 (0|0|2|0) (100.0%)       |
> > |       cbehrens       |        2 (0|0|2|0) (100.0%)       |
> > |       Sumanth        |        2 (0|0|2|0) (100.0%)       |
> > |         ttx          |         1 (0|1|0|0) (0.0%)        |
> > |       rvaknin        |         1 (0|1|0|0) (0.0%)        |
> > |     rohitkarajgi     |         1 (0|1|0|0) (0.0%)        |
> > |       ndipanov       |         1 (0|1|0|0) (0.0%)        |
> > |   michaeltchapman    |         1 (0|1|0|0) (0.0%)        |
> > |       maurosr        |         1 (0|1|0|0) (0.0%)        |
> > |      mate-lakat      |         1 (0|1|0|0) (0.0%)        |
> > |       jecarey        |         1 (0|1|0|0) (0.0%)        |
> > |         jdc          |         1 (0|1|0|0) (0.0%)        |
> > |      hartsocks       |         1 (0|1|0|0) (0.0%)        |
> > |        flwang        |         1 (0|1|0|0) (0.0%)        |
> > |      dscannell       |         1 (0|1|0|0) (0.0%)        |
> > |        blk-u         |         1 (0|1|0|0) (0.0%)        |
> > |       JordanP        |         1 (0|1|0|0) (0.0%)        |
> > |       zhhuabj        |        1 (0|0|1|0) (100.0%)       |
> > |       zhaoqin        |        1 (0|0|1|0) (100.0%)       |
> > |      yoshimatsu      |        1 (0|0|1|0) (100.0%)       |
> > |      vsergeyev       |        1 (0|0|1|0) (100.0%)       |
> > |       unknown        |        1 (0|0|1|0) (100.0%)       |
> > |        tmello        |        1 (0|0|1|0) (100.0%)       |
> > |       tkammer        |        1 (0|0|1|0) (100.0%)       |
> > |      thang.pham      |        1 (0|0|1|0) (100.0%)       |
> > |    syerrapragada     |        1 (0|0|1|0) (100.0%)       |
> > |        swann         |        1 (0|0|1|0) (100.0%)       |
> > |        sthaha        |        1 (0|0|1|0) (100.0%)       |
> > |        sileht        |        1 (0|0|1|0) (100.0%)       |
> > |         seif         |        1 (0|0|1|0) (100.0%)       |
> > |       saurabh        |        1 (0|0|1|0) (100.0%)       |
> > |        novel         |        1 (0|0|1|0) (100.0%)       |
> > |       mpavlase       |        1 (0|0|1|0) (100.0%)       |
> > |       mapleoin       |        1 (0|0|1|0) (100.0%)       |
> > |       kadachi        |        1 (0|0|1|0) (100.0%)       |
> > |     johngarbutt      |        1 (0|0|1|0) (100.0%)       |
> > |    john-griffith     |        1 (0|0|1|0) (100.0%)       |
> > |    jerome-gallard    |        1 (0|0|1|0) (100.0%)       |
> > |       jdanjou        |        1 (0|0|1|0) (100.0%)       |
> > |       guochbo        |        1 (0|0|1|0) (100.0%)       |
> > |        danms         |        1 (0|0|1|0) (100.0%)       |
> > |       cboylan        |        1 (0|0|1|0) (100.0%)       |
> > |       asalkeld       |        1 (0|0|1|0) (100.0%)       |
> > |        arosen        |        1 (0|0|1|0) (100.0%)       |
> > |  armando-migliaccio  |        1 (0|0|1|0) (100.0%)       |
> > |         alla         |        1 (0|0|1|0) (100.0%)       |
> > |      aji-zqfan       |        1 (0|0|1|0) (100.0%)       |
> > |        Liang         |        1 (0|0|1|0) (100.0%)       |
> > +----------------------+-----------------------------------+
> >
> >
> >       -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 18
> Date: Wed, 11 Sep 2013 16:51:34 -0400
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [qa] nominations for tempest-core
> Message-ID: <5230D7D6.80003 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> +1 for both.
>
> On 09/11/2013 04:32 PM, Sean Dague wrote:
> > We're in Feature Freeze for the Open Stack projects, which actually
> > means we're starting the busy cycle for Tempest in people landing
> > additional tests for verification of features that hadn't gone in until
> > recently. As such, I think now is a good time to consider some new core
> > members. There are two people I think have been doing an exceptional job
> > that we should include in the core group
> >
> > Mark Koderer has been spear heading the stress testing in Tempest,
> > completing the new stress testing for the H3 milestone, and has gotten
> > very active in reviews over the last three months.
> >
> > You can see his contributions here:
> >
> https://review.openstack.org/#/q/project:openstack/tempest+owner:m.koderer%2540telekom.de,n,z
> >
> >
> > And his code reviews here: his reviews here -
> >
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:m.koderer%2540telekom.de,n,z
> >
> >
> >
> > Giulio Fidente did a lot of great work bringing our volumes testing up
> > to par early in the cycle, and has been very active in reviews since the
> > Havana cycle opened up.
> >
> > You can see his contributions here:
> >
> https://review.openstack.org/#/q/project:openstack/tempest+owner:gfidente%2540redhat.com,n,z
> >
> >
> > And his code reviews here: his reviews here -
> >
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:gfidente%2540redhat.com,n,z
> >
> >
> >
> > Both have been active in blueprints and the openstack-qa meetings all
> > summer long, and I think would make excellent additions to the Tempest
> > core team.
> >
> > Current QA core members, please vote +1 or -1 to these nominations when
> > you get a chance. We'll keep the polls open for 5 days or until everyone
> > has voiced their votes.
> >
> > For reference here are the 90 day review stats for Tempest as of today:
> >
> > Reviews for the last 90 days in tempest
> > ** -- tempest-core team member
> > +----------------------+-----------------------------------+
> > |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |
> > +----------------------+-----------------------------------+
> > |     afazekas **      |     275 (1|29|18|227) (89.1%)     |
> > |      sdague **       |      198 (4|60|0|134) (67.7%)     |
> > |       gfidente       |      130 (0|55|75|0) (57.7%)      |
> > |    david-kranz **    |      112 (1|24|0|87) (77.7%)      |
> > |     treinish **      |      109 (5|32|0|72) (66.1%)      |
> > |      cyeoh-0 **      |       87 (0|19|4|64) (78.2%)      |
> > |       mkoderer       |       69 (0|20|49|0) (71.0%)      |
> > |     jaypipes **      |       65 (0|22|0|43) (66.2%)      |
> > |        igawa         |       49 (0|10|39|0) (79.6%)      |
> > |       oomichi        |       30 (0|9|21|0) (70.0%)       |
> > |         jogo         |       26 (0|12|14|0) (53.8%)      |
> > |       adalbas        |       22 (0|4|18|0) (81.8%)       |
> > | ravikumar-venkatesan |       22 (0|2|20|0) (90.9%)       |
> > |       ivan-zhu       |       21 (0|10|11|0) (52.4%)      |
> > |       mriedem        |        13 (0|4|9|0) (69.2%)       |
> > |   andrea-frittoli    |        12 (0|4|8|0) (66.7%)       |
> > |       mkollaro       |        10 (0|5|5|0) (50.0%)       |
> > |      zhikunliu       |        10 (0|4|6|0) (60.0%)       |
> > |        Anju5         |        9 (0|0|9|0) (100.0%)       |
> > |       anteaya        |        7 (0|3|4|0) (57.1%)        |
> > |         Anju         |        7 (0|0|7|0) (100.0%)       |
> > |   steve-stevebaker   |        6 (0|3|3|0) (50.0%)        |
> > |       prekarat       |        5 (0|3|2|0) (40.0%)        |
> > |        rahmu         |        5 (0|2|3|0) (60.0%)        |
> > |       psedlak        |        4 (0|3|1|0) (25.0%)        |
> > |        minsel        |        4 (0|3|1|0) (25.0%)        |
> > |    zhiteng-huang     |        3 (0|2|1|0) (33.3%)        |
> > |         maru         |        3 (0|1|2|0) (66.7%)        |
> > |       iwienand       |        3 (0|1|2|0) (66.7%)        |
> > |    FujiokaYuuichi    |        3 (0|1|2|0) (66.7%)        |
> > |        dolph         |        3 (0|0|3|0) (100.0%)       |
> > |     cthiel-suse      |        3 (0|0|3|0) (100.0%)       |
> > |    walter-boring     |         2 (0|2|0|0) (0.0%)        |
> > |        bnemec        |         2 (0|2|0|0) (0.0%)        |
> > |       lifeless       |        2 (0|1|1|0) (50.0%)        |
> > |    fabien-boucher    |        2 (0|1|1|0) (50.0%)        |
> > |     alex_gaynor      |        2 (0|1|1|0) (50.0%)        |
> > |        alaski        |        2 (0|1|1|0) (50.0%)        |
> > |       krtaylor       |        2 (0|0|2|0) (100.0%)       |
> > |       cbehrens       |        2 (0|0|2|0) (100.0%)       |
> > |       Sumanth        |        2 (0|0|2|0) (100.0%)       |
> > |         ttx          |         1 (0|1|0|0) (0.0%)        |
> > |       rvaknin        |         1 (0|1|0|0) (0.0%)        |
> > |     rohitkarajgi     |         1 (0|1|0|0) (0.0%)        |
> > |       ndipanov       |         1 (0|1|0|0) (0.0%)        |
> > |   michaeltchapman    |         1 (0|1|0|0) (0.0%)        |
> > |       maurosr        |         1 (0|1|0|0) (0.0%)        |
> > |      mate-lakat      |         1 (0|1|0|0) (0.0%)        |
> > |       jecarey        |         1 (0|1|0|0) (0.0%)        |
> > |         jdc          |         1 (0|1|0|0) (0.0%)        |
> > |      hartsocks       |         1 (0|1|0|0) (0.0%)        |
> > |        flwang        |         1 (0|1|0|0) (0.0%)        |
> > |      dscannell       |         1 (0|1|0|0) (0.0%)        |
> > |        blk-u         |         1 (0|1|0|0) (0.0%)        |
> > |       JordanP        |         1 (0|1|0|0) (0.0%)        |
> > |       zhhuabj        |        1 (0|0|1|0) (100.0%)       |
> > |       zhaoqin        |        1 (0|0|1|0) (100.0%)       |
> > |      yoshimatsu      |        1 (0|0|1|0) (100.0%)       |
> > |      vsergeyev       |        1 (0|0|1|0) (100.0%)       |
> > |       unknown        |        1 (0|0|1|0) (100.0%)       |
> > |        tmello        |        1 (0|0|1|0) (100.0%)       |
> > |       tkammer        |        1 (0|0|1|0) (100.0%)       |
> > |      thang.pham      |        1 (0|0|1|0) (100.0%)       |
> > |    syerrapragada     |        1 (0|0|1|0) (100.0%)       |
> > |        swann         |        1 (0|0|1|0) (100.0%)       |
> > |        sthaha        |        1 (0|0|1|0) (100.0%)       |
> > |        sileht        |        1 (0|0|1|0) (100.0%)       |
> > |         seif         |        1 (0|0|1|0) (100.0%)       |
> > |       saurabh        |        1 (0|0|1|0) (100.0%)       |
> > |        novel         |        1 (0|0|1|0) (100.0%)       |
> > |       mpavlase       |        1 (0|0|1|0) (100.0%)       |
> > |       mapleoin       |        1 (0|0|1|0) (100.0%)       |
> > |       kadachi        |        1 (0|0|1|0) (100.0%)       |
> > |     johngarbutt      |        1 (0|0|1|0) (100.0%)       |
> > |    john-griffith     |        1 (0|0|1|0) (100.0%)       |
> > |    jerome-gallard    |        1 (0|0|1|0) (100.0%)       |
> > |       jdanjou        |        1 (0|0|1|0) (100.0%)       |
> > |       guochbo        |        1 (0|0|1|0) (100.0%)       |
> > |        danms         |        1 (0|0|1|0) (100.0%)       |
> > |       cboylan        |        1 (0|0|1|0) (100.0%)       |
> > |       asalkeld       |        1 (0|0|1|0) (100.0%)       |
> > |        arosen        |        1 (0|0|1|0) (100.0%)       |
> > |  armando-migliaccio  |        1 (0|0|1|0) (100.0%)       |
> > |         alla         |        1 (0|0|1|0) (100.0%)       |
> > |      aji-zqfan       |        1 (0|0|1|0) (100.0%)       |
> > |        Liang         |        1 (0|0|1|0) (100.0%)       |
> > +----------------------+-----------------------------------+
> >
> >
> >      -Sean
> >
>
>
>
>
> ------------------------------
>
> Message: 19
> Date: Wed, 11 Sep 2013 16:57:14 -0400
> From: Mark McClain <mark.mcclain at dreamhost.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Need some clarity on security
>         group   protocol numbers vs names
> Message-ID: <B7AC7707-E53A-4020-8876-8A81A39F2095 at dreamhost.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Sep 11, 2013, at 1:46 PM, Akihiro Motoki <amotoki at gmail.com> wrote:
> >
> > On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond
> > <justin.hammond at rackspace.com> wrote:
> >> As it seems the review is no longer the place for this discussion, I
> will
> >> copy/paste my inline comments here:
> >>
> >> I dislike the idea of passing magical numbers around to define protocols
> >> (defined or otherwise). I believe there should be a common set of
> >> protocols with their numbers mapped (such as this constants business)
> and
> >> a well defined way to validate/list said common constants.
> >
> > I agree that value should be validated appropriately in general.
> > A configurable list of allowed protocols looks good to me.
>
> I'm -2.  The original bug has morphed into a mini-feature and is not
> allowable under our feature freeze rules.
>
> There are many valid reasons for allowing 41, 47, etc to a guest and we
> should continue to allow 0<=proto_num<=255 in Havana.  We should also
> refocus on the original bug intent and normalize the data to prevent
> duplicate rules in the common cases (tcp, udp, icmp, icmp, icmpv6).
>
> Any other changes should be open for discussion in Icehouse as we'll need
> to consider the deployment and backwards compatibility issues.  Feel free
> to proposal a session on this for the Hong Kong summit.
>
> mark
>
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 11 Sep 2013 17:05:29 -0400
> From: Adam Young <ayoung at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID: <5230DB19.8000403 at redhat.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> On 09/11/2013 12:35 PM, Dolph Mathews wrote:
> >
> > On Wed, Sep 11, 2013 at 10:25 AM, Adam Young <ayoung at redhat.com
> > <mailto:ayoung at redhat.com>> wrote:
> >
> >     David Chadwick wrote up an in depth API extension for Federation:
> >     https://review.openstack.org/#/c/39499
> >     There is an abfab API proposal as well:
> >     https://review.openstack.org/#/c/42221/
> >
> >     After discussing this for a while, it dawned on me that Federation
> >     should not be something bolted on to Keystone, but rather that it
> >     was already central to the design.
> >
> >     The SQL Identity backend is a simple password store that collects
> >     users into groups.  This makes it an identity provider (IdP).
> >     Now Keystone can register multiple LDAP servers as Identity backends.
> >
> >     There are requests for SAML and ABFAB integration into Keystone as
> >     well.
> >
> >     Instead of a "Federation API"  Keystone should take the key
> >     concepts from the API and make them core concepts.  What would
> >     this mean:
> >
> >     1.  Instead of "method": "federation" "protocol": "abfab"  it
> >     would be "method": "abfab",
> >     2.  The rules about multiple round trips (phase)  would go under
> >     the "abfab" section.
> >     3.  There would not be a "protocol_data" section but rather that
> >     would be the "abfab" section as well.
> >     4.  Provider ID would be standard in the method specific section.
> >
> >
> > That sounds like it fits with the original intention of the "method"
> > portion of the auth API.
> >
> >
> >     One question that has come up has been about Providers, and
> >     whether they should be considered endpoints in the Catalog.  THere
> >     is a couple issues wiuth this:  one is that they are not something
> >     managed by OpenStack, and two is that they are not necessarily Web
> >     Protocols.
> >
> >
> > What's the use case for including providers in the service catalog?
> > i.e. why do Identity API clients need to be aware of the Identity
> > Providers?
> In the federation protocol API, the user can specify the IdP that they
> are using. Keystone needs to know what are the set of acceptable IdPs,
> somehow.  The first thought was reuse of the Service catalog.
> It probably makes sense to let an administrator enumerate the IdPs
> registered with Keystone, and what protocol each supports.
>
>
> >
> >     As such, Provider should probably be First class citizen.  We
> >     already have LDAP  handled this way, although not as an enumerated
> >     entity.
> >
> >
> > Can you be more specific? What does it mean to be a first class
> > citizen in this context? The fact that identity is backed by LDAP
> > today is abstracted away from Identity API clients, for example.
> >
> >     For the first iteration, I would like to see ABFAB, SAML, and any
> >     other protocols we support done the same way as LDAP:  a
> >     deliberate configuration option for Keystone that will require a
> >     config file change.
> >
> >     David and I have discussed this in a side conversation, and agree
> >     that it requires wider input.
> >
> >
> >
> >
> >     _______________________________________________
> >     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
> >
> >
> >
> >
> > --
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > 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/20130911/36d84934/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 21
> Date: Wed, 11 Sep 2013 17:09:52 -0400
> From: Adam Young <ayoung at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID: <5230DC20.7090404 at redhat.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> On 09/11/2013 02:35 PM, Brad Topol wrote:
> > Hi Adam,
> >
> > One thing I think we should capture before going deep into design and
> > implementation is to understand the federated identity use cases that
> > our stakeholders need us to support. I'm hoping we all can start
> > capturing these in a federated identity icehouse design summit session.
>
> Stakholders. You keep using that term.  I do not think it means what you
> think it means.
>
> In this case, we have a pretty good idea what is meant by Federation in
> general, and we know what some of the people interested in Open Stack
> want.  The more input we can get, the better.
>
> However, We know that we have requests for ABFAB and SAML integration,
> and have had discussions about them at the last Summit, so this is not
> new stuff.  What we are trying to do is figure out the commonalities of
> the various Federation approaches so we have and easily understand
> approach to integrating new providers.
> >
> > Thanks,
> >
> > Brad
> >
> > Brad Topol, Ph.D.
> > IBM Distinguished Engineer
> > OpenStack
> > (919) 543-0646
> > Internet:  btopol at us.ibm.com
> > Assistant: Cindy Willman (919) 268-5296
> >
> >
> >
> > From: Adam Young <ayoung at redhat.com>
> > To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>
> > Date: 09/11/2013 11:28 AM
> > Subject: [openstack-dev] Keystone and Multiple Identity Sources
> > ------------------------------------------------------------------------
> >
> >
> >
> > David Chadwick wrote up an in depth API extension for Federation:
> > https://review.openstack.org/#/c/39499
> > There is an abfab API proposal as well:
> > https://review.openstack.org/#/c/42221/
> >
> > After discussing this for a while, it dawned on me that Federation
> > should not be something bolted on to Keystone, but rather that it was
> > already central to the design.
> >
> > The SQL Identity backend is a simple password store that collects users
> > into groups.  This makes it an identity provider (IdP).
> > Now Keystone can register multiple LDAP servers as Identity backends.
> >
> > There are requests for SAML and ABFAB integration into Keystone as well.
> >
> > Instead of a "Federation API"  Keystone should take the key concepts
> > from the API and make them core concepts.  What would this mean:
> >
> > 1.  Instead of "method": "federation" "protocol": "abfab"  it would be
> > "method": "abfab",
> > 2.  The rules about multiple round trips (phase)  would go under the
> > "abfab" section.
> > 3.  There would not be a "protocol_data" section but rather that would
> > be the "abfab" section as well.
> > 4.  Provider ID would be standard in the method specific section.
> >
> > One question that has come up has been about Providers, and whether they
> > should be considered endpoints in the Catalog.  THere is a couple issues
> > wiuth this:  one is that they are not something managed by OpenStack,
> > and two is that they are not necessarily Web Protocols.  As such,
> > Provider should probably be First class citizen.  We already have LDAP
> > handled this way, although not as an enumerated entity.  For the first
> > iteration, I would like to see ABFAB, SAML, and any other protocols we
> > support done the same way as LDAP:  a deliberate configuration option
> > for Keystone that will require a config file change.
> >
> > David and I have discussed this in a side conversation, and agree that
> > it requires wider input.
> >
> >
> >
> >
> > _______________________________________________
> > 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/20130911/97f5079d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 22
> Date: Wed, 11 Sep 2013 17:11:50 -0400
> From: David Kranz <dkranz at redhat.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Cc: Sean Dague <sean at dague.net>
> Subject: Re: [openstack-dev] [qa] nominations for tempest-core
> Message-ID: <5230DC96.1010509 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> +1 to both!
>
> On 09/11/2013 04:32 PM, Sean Dague wrote:
> > We're in Feature Freeze for the Open Stack projects, which actually
> > means we're starting the busy cycle for Tempest in people landing
> > additional tests for verification of features that hadn't gone in
> > until recently. As such, I think now is a good time to consider some
> > new core members. There are two people I think have been doing an
> > exceptional job that we should include in the core group
> >
> > Mark Koderer has been spear heading the stress testing in Tempest,
> > completing the new stress testing for the H3 milestone, and has gotten
> > very active in reviews over the last three months.
> >
> > You can see his contributions here:
> >
> https://review.openstack.org/#/q/project:openstack/tempest+owner:m.koderer%2540telekom.de,n,z
> >
> > And his code reviews here: his reviews here -
> >
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:m.koderer%2540telekom.de,n,z
> >
> >
> > Giulio Fidente did a lot of great work bringing our volumes testing up
> > to par early in the cycle, and has been very active in reviews since
> > the Havana cycle opened up.
> >
> > You can see his contributions here:
> >
> https://review.openstack.org/#/q/project:openstack/tempest+owner:gfidente%2540redhat.com,n,z
> >
> > And his code reviews here: his reviews here -
> >
> https://review.openstack.org/#/q/project:openstack/tempest+reviewer:gfidente%2540redhat.com,n,z
> >
> >
> > Both have been active in blueprints and the openstack-qa meetings all
> > summer long, and I think would make excellent additions to the Tempest
> > core team.
> >
> > Current QA core members, please vote +1 or -1 to these nominations
> > when you get a chance. We'll keep the polls open for 5 days or until
> > everyone has voiced their votes.
> >
> > For reference here are the 90 day review stats for Tempest as of today:
> >
> > Reviews for the last 90 days in tempest
> > ** -- tempest-core team member
> > +----------------------+-----------------------------------+
> > |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |
> > +----------------------+-----------------------------------+
> > |     afazekas **      |     275 (1|29|18|227) (89.1%)     |
> > |      sdague **       |      198 (4|60|0|134) (67.7%)     |
> > |       gfidente       |      130 (0|55|75|0) (57.7%)      |
> > |    david-kranz **    |      112 (1|24|0|87) (77.7%)      |
> > |     treinish **      |      109 (5|32|0|72) (66.1%)      |
> > |      cyeoh-0 **      |       87 (0|19|4|64) (78.2%)      |
> > |       mkoderer       |       69 (0|20|49|0) (71.0%)      |
> > |     jaypipes **      |       65 (0|22|0|43) (66.2%)      |
> > |        igawa         |       49 (0|10|39|0) (79.6%)      |
> > |       oomichi        |       30 (0|9|21|0) (70.0%)       |
> > |         jogo         |       26 (0|12|14|0) (53.8%)      |
> > |       adalbas        |       22 (0|4|18|0) (81.8%)       |
> > | ravikumar-venkatesan |       22 (0|2|20|0) (90.9%)       |
> > |       ivan-zhu       |       21 (0|10|11|0) (52.4%)      |
> > |       mriedem        |        13 (0|4|9|0) (69.2%)       |
> > |   andrea-frittoli    |        12 (0|4|8|0) (66.7%)       |
> > |       mkollaro       |        10 (0|5|5|0) (50.0%)       |
> > |      zhikunliu       |        10 (0|4|6|0) (60.0%)       |
> > |        Anju5         |        9 (0|0|9|0) (100.0%)       |
> > |       anteaya        |        7 (0|3|4|0) (57.1%)        |
> > |         Anju         |        7 (0|0|7|0) (100.0%)       |
> > |   steve-stevebaker   |        6 (0|3|3|0) (50.0%)        |
> > |       prekarat       |        5 (0|3|2|0) (40.0%)        |
> > |        rahmu         |        5 (0|2|3|0) (60.0%)        |
> > |       psedlak        |        4 (0|3|1|0) (25.0%)        |
> > |        minsel        |        4 (0|3|1|0) (25.0%)        |
> > |    zhiteng-huang     |        3 (0|2|1|0) (33.3%)        |
> > |         maru         |        3 (0|1|2|0) (66.7%)        |
> > |       iwienand       |        3 (0|1|2|0) (66.7%)        |
> > |    FujiokaYuuichi    |        3 (0|1|2|0) (66.7%)        |
> > |        dolph         |        3 (0|0|3|0) (100.0%)       |
> > |     cthiel-suse      |        3 (0|0|3|0) (100.0%)       |
> > |    walter-boring     |         2 (0|2|0|0) (0.0%)        |
> > |        bnemec        |         2 (0|2|0|0) (0.0%)        |
> > |       lifeless       |        2 (0|1|1|0) (50.0%)        |
> > |    fabien-boucher    |        2 (0|1|1|0) (50.0%)        |
> > |     alex_gaynor      |        2 (0|1|1|0) (50.0%)        |
> > |        alaski        |        2 (0|1|1|0) (50.0%)        |
> > |       krtaylor       |        2 (0|0|2|0) (100.0%)       |
> > |       cbehrens       |        2 (0|0|2|0) (100.0%)       |
> > |       Sumanth        |        2 (0|0|2|0) (100.0%)       |
> > |         ttx          |         1 (0|1|0|0) (0.0%)        |
> > |       rvaknin        |         1 (0|1|0|0) (0.0%)        |
> > |     rohitkarajgi     |         1 (0|1|0|0) (0.0%)        |
> > |       ndipanov       |         1 (0|1|0|0) (0.0%)        |
> > |   michaeltchapman    |         1 (0|1|0|0) (0.0%)        |
> > |       maurosr        |         1 (0|1|0|0) (0.0%)        |
> > |      mate-lakat      |         1 (0|1|0|0) (0.0%)        |
> > |       jecarey        |         1 (0|1|0|0) (0.0%)        |
> > |         jdc          |         1 (0|1|0|0) (0.0%)        |
> > |      hartsocks       |         1 (0|1|0|0) (0.0%)        |
> > |        flwang        |         1 (0|1|0|0) (0.0%)        |
> > |      dscannell       |         1 (0|1|0|0) (0.0%)        |
> > |        blk-u         |         1 (0|1|0|0) (0.0%)        |
> > |       JordanP        |         1 (0|1|0|0) (0.0%)        |
> > |       zhhuabj        |        1 (0|0|1|0) (100.0%)       |
> > |       zhaoqin        |        1 (0|0|1|0) (100.0%)       |
> > |      yoshimatsu      |        1 (0|0|1|0) (100.0%)       |
> > |      vsergeyev       |        1 (0|0|1|0) (100.0%)       |
> > |       unknown        |        1 (0|0|1|0) (100.0%)       |
> > |        tmello        |        1 (0|0|1|0) (100.0%)       |
> > |       tkammer        |        1 (0|0|1|0) (100.0%)       |
> > |      thang.pham      |        1 (0|0|1|0) (100.0%)       |
> > |    syerrapragada     |        1 (0|0|1|0) (100.0%)       |
> > |        swann         |        1 (0|0|1|0) (100.0%)       |
> > |        sthaha        |        1 (0|0|1|0) (100.0%)       |
> > |        sileht        |        1 (0|0|1|0) (100.0%)       |
> > |         seif         |        1 (0|0|1|0) (100.0%)       |
> > |       saurabh        |        1 (0|0|1|0) (100.0%)       |
> > |        novel         |        1 (0|0|1|0) (100.0%)       |
> > |       mpavlase       |        1 (0|0|1|0) (100.0%)       |
> > |       mapleoin       |        1 (0|0|1|0) (100.0%)       |
> > |       kadachi        |        1 (0|0|1|0) (100.0%)       |
> > |     johngarbutt      |        1 (0|0|1|0) (100.0%)       |
> > |    john-griffith     |        1 (0|0|1|0) (100.0%)       |
> > |    jerome-gallard    |        1 (0|0|1|0) (100.0%)       |
> > |       jdanjou        |        1 (0|0|1|0) (100.0%)       |
> > |       guochbo        |        1 (0|0|1|0) (100.0%)       |
> > |        danms         |        1 (0|0|1|0) (100.0%)       |
> > |       cboylan        |        1 (0|0|1|0) (100.0%)       |
> > |       asalkeld       |        1 (0|0|1|0) (100.0%)       |
> > |        arosen        |        1 (0|0|1|0) (100.0%)       |
> > |  armando-migliaccio  |        1 (0|0|1|0) (100.0%)       |
> > |         alla         |        1 (0|0|1|0) (100.0%)       |
> > |      aji-zqfan       |        1 (0|0|1|0) (100.0%)       |
> > |        Liang         |        1 (0|0|1|0) (100.0%)       |
> > +----------------------+-----------------------------------+
> >
> >
> >     -Sean
> >
>
>
>
>
> ------------------------------
>
> Message: 23
> Date: Wed, 11 Sep 2013 17:12:03 -0400
> From: Adam Young <ayoung at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Keystone and Multiple Identity Sources
> Message-ID: <5230DCA3.5010101 at redhat.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> On 09/11/2013 02:05 PM, Dolph Mathews wrote:
> >
> > On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick
> > <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
> >
> >     Further supplementary information to Adam's email below, is that
> >     there are already one further federation protocol profiles that
> >     has been published:
> >     for an external Keystone acting as an IdP at
> >     https://review.openstack.org/#/c/42107/
> >
> >     and another for SAML has been prepared and is ready for publication.
> >
> >     I would expect several additional federation profiles to be
> >     published in the future, for example, for OpenID Connect and what
> >     ever else might be just around the corner.
> >
> >     Given the fact that the number of federation protocols is not
> >     fixed, and will evolve with time, then I would prefer their method
> >     of integration into Keystone to be common, so that one
> >     "federation" module can handle all the non-protocol specific
> >     federation features, such as policy and trust checking, and this
> >     module can have multiple different protocol handling modules
> >     plugged into it that deal with the protocol specific features
> >     only. This is the method we have adopted in our current
> >     implementation of federation, and have shown that it is a viable
> >     and efficient way of implementation as we currently support three
> >     protocol profiles (SAML, ABFAB and External Keystone).
> >
> >     Thus I prefer
> >
> >     "method": "federation" "protocol": "abfab"
> >
> >     in which the abfab part would be replaced by the particular
> >     protocol, and there are common parameters to be used by the
> >     federation module
> >
> >
> >     instead of "method": "abfab"
> >
> >     as the latter removes the common parameters from federation, and
> >     also means that common code wont be used, unless it is cut and
> >     paste into each protocol specific module.
> >
> >
> > That sounds like a pretty strong argument in favor of the current
> > design, assuming the "abfab" parameters are children of the common
> > "federation" parameters (rather than a sibling of the "federation"
> > parameters)... which does appear to be the case the current patchset-
> > https://review.openstack.org/#/c/42221/
>
> And this is where David and I disagree.  I don't think Federation is "in
> addition to Keystone" but rather it is fundamental to Keystone. I don't
> think "method" :" federation"  is a necessary abstraction. I think what
> David is trying to acheive is best done as a set of standards on how to
> add any provider:  we don't need a wrapper around a wrapper.
>
> >
> >     Comments?
> >
> >     David
> >
> >
> >
> >     On 11/09/2013 16:25, Adam Young wrote:
> >
> >         David Chadwick wrote up an in depth API extension for Federation:
> >         https://review.openstack.org/#/c/39499
> >         There is an abfab API proposal as well:
> >         https://review.openstack.org/#/c/42221/
> >
> >         After discussing this for a while, it dawned on me that
> Federation
> >         should not be something bolted on to Keystone, but rather that
> >         it was
> >         already central to the design.
> >
> >         The SQL Identity backend is a simple password store that
> >         collects users
> >         into groups.  This makes it an identity provider (IdP).
> >         Now Keystone can register multiple LDAP servers as Identity
> >         backends.
> >
> >         There are requests for SAML and ABFAB integration into
> >         Keystone as well.
> >
> >         Instead of a "Federation API"  Keystone should take the key
> >         concepts
> >         from the API and make them core concepts.  What would this mean:
> >
> >         1.  Instead of "method": "federation" "protocol": "abfab"  it
> >         would be
> >         "method": "abfab",
> >         2.  The rules about multiple round trips (phase)  would go
> >         under the
> >         "abfab" section.
> >         3.  There would not be a "protocol_data" section but rather
> >         that would
> >         be the "abfab" section as well.
> >         4.  Provider ID would be standard in the method specific section.
> >
> >         One question that has come up has been about Providers, and
> >         whether they
> >         should be considered endpoints in the Catalog.  THere is a
> >         couple issues
> >         wiuth this:  one is that they are not something managed by
> >         OpenStack,
> >         and two is that they are not necessarily Web Protocols.  As such,
> >         Provider should probably be First class citizen.  We already
> >         have LDAP
> >         handled this way, although not as an enumerated entity.  For
> >         the first
> >         iteration, I would like to see ABFAB, SAML, and any other
> >         protocols we
> >         support done the same way as LDAP:  a deliberate configuration
> >         option
> >         for Keystone that will require a config file change.
> >
> >         David and I have discussed this in a side conversation, and
> >         agree that
> >         it requires wider input.
> >
> >
> >
> >
> >         _______________________________________________
> >         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
> >
> >
> >
> >
> > --
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > 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/20130911/13550477/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 24
> Date: Wed, 11 Sep 2013 17:13:00 -0400
> From: Marc PINHEDE <pinhede.marc at netvirt.ca>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [Neutron] New plugin
> Message-ID:
>         <
> CA+MiSASVt_2-0TifBFQ7th9EbTfS48rsvZgY9oPDe+5M9jOXxQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> I am Marc Pinh?de, working in Netvirt with professor Omar Cherkaoui.
>
> We started working on a Neutron plugin. A first version is now almost
> ready.
> To inform the community, we posted a blueprint:
>
> https://blueprints.launchpad.net/neutron/+spec/modular-adaptative-plugin
>
> We would like to make our code available soon. But wiki page
> https://wiki.openstack.org/wiki/NeutronDevelopment does not gives many
> clues on where and how to post code.
>
> As Havana is in feature-freeze stage, discussions on the blueprint and
> eventual integration in Neutron core may come once Havana would be
> released.
>
> Waiting for this, where is the better place to make our code available?
>
> Marc Pinh?de
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/b616576c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 25
> Date: Wed, 11 Sep 2013 23:29:00 +0200
> From: Salvatore Orlando <sorlando at nicira.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] New plugin
> Message-ID:
>         <CAGR=
> i3h0nkO2LE5iYNPq5MvZy62m2E7UM+sOMazoZJxd597pAA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Marc,
>
> Perhaps this guide [1] might help you going through the process of signign
> the CLA and pushing your code to gerrit for review.
>
> Salvatore
>
> [1] https://wiki.openstack.org/wiki/How_To_Contribute
>
>
> On 11 September 2013 23:13, Marc PINHEDE <pinhede.marc at netvirt.ca> wrote:
>
> > Hello,
> >
> > I am Marc Pinh?de, working in Netvirt with professor Omar Cherkaoui.
> >
> > We started working on a Neutron plugin. A first version is now almost
> > ready.
> > To inform the community, we posted a blueprint:
> >
> > https://blueprints.launchpad.net/neutron/+spec/modular-adaptative-plugin
> >
> > We would like to make our code available soon. But wiki page
> > https://wiki.openstack.org/wiki/NeutronDevelopment does not gives many
> > clues on where and how to post code.
> >
> > As Havana is in feature-freeze stage, discussions on the blueprint and
> > eventual integration in Neutron core may come once Havana would be
> released.
> >
> > Waiting for this, where is the better place to make our code available?
> >
> > Marc Pinh?de
> >
> > _______________________________________________
> > 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/20130911/22028122/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 26
> Date: Wed, 11 Sep 2013 22:03:01 +0000
> From: "Arvind Somya (asomya)" <asomya at cisco.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Need some clarity on security
>         group protocol numbers vs names
> Message-ID:
>         <8341333BAC6D9B49AD9CE07CADEA300B13DCDB3B at xmb-rcd-x10.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ok, those were some good points. I personally like the approach of letting
> each implementation specify it's own set of supported protocols.
>
> I'll change my patch to simply convert all protocols to names (more
> readable).
>
>
> Thanks
> Arvind
>
> On 9/11/13 3:06 PM, "Justin Hammond" <justin.hammond at RACKSPACE.COM> wrote:
>
> >I agree with you. Plugin was a mere example and it does make sense to
> >allow the provider to define custom protocols.
> >
> >+1
> >
> >On 9/11/13 12:46 PM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
> >
> >>Hi Justin,
> >>
> >>My point is what
> >>
> >>On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond
> >><justin.hammond at rackspace.com> wrote:
> >>> As it seems the review is no longer the place for this discussion, I
> >>>will
> >>> copy/paste my inline comments here:
> >>>
> >>> I dislike the idea of passing magical numbers around to define
> >>>protocols
> >>> (defined or otherwise). I believe there should be a common set of
> >>> protocols with their numbers mapped (such as this constants business)
> >>>and
> >>> a well defined way to validate/list said common constants.
> >>
> >>I agree that value should be validated appropriately in general.
> >>A configurable list of allowed protocols looks good to me.
> >>
> >>> wishes to add support for a protocol outside of the common case, it
> >>>should
> >>> be added to the list in a pluggable manner.
> >>> Ex: common defines the constants 1, 6, 17 to be valid but
> >>>my_cool_plugin
> >>> wants to support 42. It should be my plugin's responsibility to add 42
> >>>to
> >>> the list of valid protocols by appending to the list given a pluggable
> >>> interface to do so. I do not believe plugins should continue to update
> >>>the
> >>> common.constants file with new protocols, but I do believe explicitly
> >>> stating which protocols are valid is better than allowing users to
> >>> possibly submit protocols erroneously.
> >>
> >>I think this is just a case a backend plugin defines allowed protocols.
> >>
> >>I also see a different case: a cloud provider defines allowed protocols.
> >>For example VLAN network type of OVS plugin can convey any type of
> >>packets
> >>including GRE, STCP and so on if a provider wants to do so.
> >>We need to allow a provider to configure the list.
> >>
> >>Considering the above, what we need to do looks:
> >>(a) to validate values properly,
> >>(b) to allow a plugin to define what protocols should be allowed
> >>    (I think we need two types of lists: possible protocols and
> >>default allowed protocols)
> >>(c) to allow a cloud provider (deployer) to customize allow protocols.
> >>    (Of course (c) is a subnet of "possible protocols" in (b))
> >>
> >>Does it make sense?
> >>The above is just a start point of the discussion and some list can be
> >>omitted.
> >>
> >># Whether (c) is needed or not depends on the default list of (b).
> >># If it is wide enough (c) is not needed. The current list of (b) is
> >>[tcp, udp, icmp]
> >># and it looks too small set to me, so it is better to have (c) too.
> >>
> >>> If the plugins use a system such as this, it is possible that new,
> >>>common,
> >>> protocols can be found to be core. See NETWORK_TYPE constants.
> >>
> >>I think the situation is a bit different. What network types are
> >>allowed is tightly
> >>coupled with a plugin implementation, and a cloud provider choose a
> >>plugin
> >>based on their needs. Thus the mechanism of NETWORK_TYPE constants
> >>make sense to me too.
> >>
> >>> tl;dr: magic constants are no good, but values should be validated in a
> >>> pluggable and explicit manner.
> >>
> >>As I said above, I agree it is important to validate values properly in
> >>general.
> >>
> >>Thanks,
> >>Akihiro
> >>
> >>>
> >>>
> >>>
> >>> On 9/11/13 10:40 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
> >>>
> >>>>Hi all,
> >>>>
> >>>>Arvind, thank you for initiate the discussion about the ip protocol in
> >>>>security group rules.
> >>>>I think the discussion point can be broken down into:
> >>>>
> >>>>(a) how to specify ip protocol : by name, number, or both
> >>>>(b) what ip protocols can be specified: known protocols only, all
> >>>>protocols (or some subset of protocols including unknown protocols)
> >>>>     where "known protocols" is defined as a list in Neutron (a list
> >>>>of constants or a configurable list)
> >>>>
> >>>>------
> >>>>(b) is the main topic Arvind and I discussed in the review.
> >>>>If only known protocols are allowed, we cannot allow protocols which
> >>>>are not listed in the known protocol list.
> >>>>For instance, if "tcp", "udp" and "icmp" are registered as known
> >>>>protocols (this is the current neutron implementation),
> >>>>a tenant cannot allow "stcp" or "gre".
> >>>>
> >>>>Pros of "known protocols only" is the infrastructure provider can
> >>>>control which protocols are allowed.
> >>>>Cons is that users cannot use ip protocols not listed in a known list
> >>>>and a provider needs to maintain a known protocol list.
> >>>>Pros and cons of "all protocols allowed" is vice versa.
> >>>>
> >>>>If a list of known protocols is configurable, we can cover both cases,
> >>>>e.g., an empty list or a list ["ANY"] means all protocols are allowed.
> >>>>The question in this case is what is the best default value.
> >>>>
> >>>>My preference is to allow all protocols. At least a list of known
> >>>>protocols needs to be configurable.
> >>>>In my principle, a virtual network should be able to convery any type
> >>>>of IP protocols in a virtual network. This is the reason of my
> >>>>preference.
> >>>>
> >>>>-----
> >>>>Regarding (a), if a name and a number refer to a same protocol, it
> >>>>should be considered as identical.
> >>>>For example, ip protocol number 6 is "tcp", so ip protocol number 6
> >>>>and protocol name "tcp" should be regarded as same.
> >>>>My preference is to allow both name and number of IP protocol. This
> >>>>will be achieved by Arvind's patch under the review.
> >>>>"name" representation is easy to understand in general, but
> >>>>maintaining all protocol names is a tough work.
> >>>>This is the reason of my preference.
> >>>>
> >>>>
> >>>>I understand there is a topic whether a list of known protocols should
> >>>>contain name only or accepts both name and number.
> >>>>I don't discuss it here because it is a simple question once we have a
> >>>>consensus on the above two topic.
> >>>>
> >>>>Thanks,
> >>>>Akihiro
> >>>>
> >>>>On Wed, Sep 11, 2013 at 11:15 PM, Arvind Somya (asomya)
> >>>><asomya at cisco.com> wrote:
> >>>>> Hello all
> >>>>>
> >>>>> I have a patch in review where  Akihiro made some comments about only
> >>>>> restricting protocols by names and allowing all protocol numbers when
> >>>>> creating security group rules. I personally disagree with this
> >>>>>approach
> >>>>>as
> >>>>> names and numbers are just a textual/integer representation of a
> >>>>>common
> >>>>> protocol. The end result is going to be the same in both cases.
> >>>>>
> >>>>> https://review.openstack.org/#/c/43725/
> >>>>>
> >>>>> Akihiro suggested a community discussion around this issue before the
> >>>>>patch
> >>>>> is accepted upstream. I hope this e-mail gets the ball rolling on
> >>>>>that.
> >>>>>I
> >>>>> would like to hear the community's opinion on this issue and any
> >>>>> pros/cons/pitfalls of either approach.
> >>>>>
> >>>>> Thanks
> >>>>> Arvind
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>--
> >>>>Akihiro MOTOKI <amotoki at gmail.com>
> >>>>
> >>>>_______________________________________________
> >>>>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
> >>
> >>--
> >>Akihiro MOTOKI <amotoki at gmail.com>
> >>
> >>_______________________________________________
> >>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: 27
> Date: Wed, 11 Sep 2013 22:58:49 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [State-Management] Agenda for tommorow
>         meeting at      2000 UTC
> Message-ID: <CE5643B5.478B0%harlowja at yahoo-inc.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> The [state-management] project team holds a weekly meeting in
> #openstack-meeting on thursdays, 2000 UTC. The next meeting is tommorow,
> 2013-09-12!!!
>
> As usual, everyone is welcome :-)
>
> Link: https://wiki.openstack.org/wiki/Meetings/StateManagement
> Taskflow: https://wiki.openstack.org/TaskFlow
>
> ## Agenda (30-60 mins):
>
> - Discuss any action items from last meeting.
> - Discuss ongoing status of the overall effort and any needed coordination.
> - Discuss progress on graph pattern and action engine implementation.
> - Discuss how the work on resumption is going, any issues or other
> discussions releated to this.
> - Discuss new blueprint for progress tracking -
> https://blueprints.launchpad.net/taskflow/+spec/task-progress
> - Discuss new state wiki -
> https://wiki.openstack.org/wiki/TaskFlow/States_of_Task_and_Flow
> - Discuss about any other potential new use-cases for said library.
> - Discuss about any other ideas, problems, open-reviews, issues,
> solutions, questions (and more).
>
> Any other topics are welcome :-)
>
> See you all soon!
>
> --
>
> Joshua Harlow
>
> It's openstack, relax... | harlowja at yahoo-inc.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/f16e26e8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 28
> Date: Thu, 12 Sep 2013 01:07:03 +0000
> From: Keith Bray <keith.bray at RACKSPACE.COM>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] How the autoscale API should
>         control scaling in Heat
> Message-ID: <CE567D42.7C147%keith.bray at rackspace.com>
> Content-Type: text/plain; charset="us-ascii"
>
> There is context missing here.  heat==>trove interaction is through the
> trove API.  trove==>heat interaction is a _different_ instance of Heat,
> internal to trove's infrastructure setup, potentially provisioning
> instances.   Public Heat wouldn't be creating instances and then telling
> trove to make them into databases.
>
> At least, that's what I understand from conversations with the Trove
> folks.  I could be wrong here also.
>
> -Keith
>
> On 9/11/13 11:11 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
>
> >Sure,
> >
> >I was thinking that since heat would do autoscaling persay, then heat
> >would say ask trove to make more databases (autoscale policy here) then
> >this would cause trove to actually callback into heat to make more
> >instances.
> >
> >Just feels a little weird, idk.
> >
> >Why didn't heat just make those instances "on behalf of trove" to begin
> >with and then tell trove "make these instances into databases". Then
> >trove doesn't really need to worry about calling into heat to do the
> >instance creation "work", and trove can just worry about converting those
> >"blank instances " into databases (for example).
> >
> >But maybe I am missing other context also :)
> >
> >Sent from my really tiny device...
> >
> >On Sep 11, 2013, at 8:04 AM, "Clint Byrum" <clint at fewbar.com> wrote:
> >
> >> Excerpts from Joshua Harlow's message of 2013-09-11 01:00:37 -0700:
> >>> +1
> >>>
> >>> The assertions are not just applicable to autoscaling but to software
> >>>in general. I hope we can make autoscaling "just enough" simple to work.
> >>>
> >>> The circular heat<=>trove example is one of those that does worry me a
> >>>little. It feels like something is not structured right if that it is
> >>>needed (rube goldberg like). I am not sure what could be done
> >>>differently, just my gut feeling that something is "off".
> >>
> >> Joshua, can you elaborate on "the circular heat<=>trove example"?
> >>
> >> I don't see Heat and Trove's relationship as circular. Heat has a Trove
> >> resource, and (soon? now?) Trove can use Heat to simplify its control
> >> of underlying systems. This is a stack, not a circle, or did I miss
> >> something?
> >>
> >> _______________________________________________
> >> 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: 29
> Date: Thu, 12 Sep 2013 09:12:08 +0800
> From: yongli he <yongli.he at intel.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails
>         with "NameError: global name '_' is not defined"
> Message-ID: <523114E8.6070906 at intel.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> ? 2013?09?11? 21:27, Henry Gessau ??:
> > For the "TypeError: expected string or buffer" I have filed Bug #1223874.
> got? thanks?
> >
> >
> > On Wed, Sep 11, at 7:41 am, yongli he <yongli.he at intel.com> wrote:
> >
> >> ? 2013?09?11? 05:38, David Kang ??:
> >>> ----- Original Message -----
> >>>> From: "Russell Bryant" <rbryant at redhat.com>
> >>>> To: "David Kang" <dkang at isi.edu>
> >>>> Cc: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> >>>> Sent: Tuesday, September 10, 2013 5:17:15 PM
> >>>> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails
> with "NameError: global name '_' is not defined"
> >>>> On 09/10/2013 05:03 PM, David Kang wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Russell Bryant" <rbryant at redhat.com>
> >>>>>> To: "OpenStack Development Mailing List"
> >>>>>> <openstack-dev at lists.openstack.org>
> >>>>>> Cc: "David Kang" <dkang at isi.edu>
> >>>>>> Sent: Tuesday, September 10, 2013 4:42:41 PM
> >>>>>> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails
> >>>>>> with "NameError: global name '_' is not defined"
> >>>>>> On 09/10/2013 03:56 PM, David Kang wrote:
> >>>>>>>    Hi,
> >>>>>>>
> >>>>>>>     I'm trying to test pci device passthrough feature.
> >>>>>>> Havana3 is installed using Packstack on CentOS 6.4.
> >>>>>>> Nova-compute dies right after start with error "NameError: global
> >>>>>>> name '_' is not defined".
> >>>>>>> I'm not sure if it is due to misconfiguration of nova.conf or bug.
> >>>>>>> Any help will be appreciated.
> >>>>>>>
> >>>>>>> Here is the info:
> >>>>>>>
> >>>>>>> /etc/nova/nova.conf:
> >>>>>>> pci_alias={"name":"test", "product_id":"7190", "vendor_id":"8086",
> >>>>>>> "device_type":"ACCEL"}
> >>>>>>>
> >>>>>>>
> pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"7190"}]
> >>>>>>>
> >>>>>>>    With that configuration, nova-compute fails with the following
> >>>>>>>    log:
> >>>>>>>
> >>>>>>>     File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>>>>     line 461, in _process_data
> >>>>>>>       **args)
> >>>>>>>
> >>>>>>>     File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >>>>>>>     line 172, in dispatch
> >>>>>>>       result = getattr(proxyobj, method)(ctxt, **kwargs)
> >>>>>>>
> >>>>>>>     File
> >>>>>>>     "/usr/lib/python2.6/site-packages/nova/conductor/manager.py",
> >>>>>>>     line 567, in object_action
> >>>>>>>       result = getattr(objinst, objmethod)(context, *args,
> **kwargs)
> >>>>>>>
> >>>>>>>     File "/usr/lib/python2.6/site-packages/nova/objects/base.py",
> >>>>>>>     line
> >>>>>>>     141, in wrapper
> >>>>>>>       return fn(self, ctxt, *args, **kwargs)
> >>>>>>>
> >>>>>>>     File
> >>>>>>>     "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >>>>>>>     line 242, in save
> >>>>>>>       self._from_db_object(context, self, db_pci)
> >>>>>>>
> >>>>>>> NameError: global name '_' is not defined
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup Traceback (most recent call
> >>>>>>> last):
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>>>>>> line 117, in wait
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup x.wait()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>>>>>> line 49, in wait
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return self.thread.wait()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>>>>>> 166, in wait
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return self._exit_event.wait()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in
> >>>>>>> wait
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return hubs.get_hub().switch()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177,
> >>>>>>> in switch
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return self.greenlet.switch()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>>>>>> 192, in main
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup result = function(*args,
> >>>>>>> **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py",
> >>>>>>> line 65, in run_service
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup service.start()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in
> >>>>>>> start
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup self.manager.pre_start_hook()
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> >>>>>>> 805, in pre_start_hook
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> self.update_available_resource(nova.context.get_admin_context())
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> >>>>>>> 4773, in update_available_resource
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> rt.update_available_resource(context)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py",
> >>>>>>> line 246, in inner
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return f(*args, **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>>>> line 318, in update_available_resource
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup self._sync_compute_node(context,
> >>>>>>> resources)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>>>> line 347, in _sync_compute_node
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup self._update(context, resources,
> >>>>>>> prune_stats=True)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>>>> line 420, in _update
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup self.pci_tracker.save(context)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/pci/pci_manager.py", line
> >>>>>>> 126, in save
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup dev.save(context)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 134,
> >>>>>>> in wrapper
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup ctxt, self, fn.__name__, args,
> >>>>>>> kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/conductor/rpcapi.py", line
> >>>>>>> 497, in object_action
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup objmethod=objmethod, args=args,
> >>>>>>> kwargs=kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 85, in
> >>>>>>> call
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return
> >>>>>>> self._invoke(self.proxy.call, ctxt, method, **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 63, in
> >>>>>>> _invoke
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return cast_or_call(ctxt, msg,
> >>>>>>> **self.kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/proxy.py",
> >>>>>>> line 126, in call
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup result = rpc.call(context,
> >>>>>>> real_topic, msg, timeout)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/__init__.py",
> >>>>>>> line 139, in call
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return _get_impl().call(CONF,
> >>>>>>> context, topic, msg, timeout)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py",
> >>>>>>> line 794, in call
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> rpc_amqp.get_connection_pool(conf,
> >>>>>>> Connection))
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>>>> line 574, in call
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup rv = list(rv)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>>>> line 539, in __iter__
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup raise result
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup NameError: global name '_' is
> >>>>>>> not
> >>>>>>> defined
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup Traceback (most recent call
> >>>>>>> last):
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>>>> line 461, in _process_data
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup **args)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >>>>>>> line 172, in dispatch
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup result = getattr(proxyobj,
> >>>>>>> method)(ctxt, **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/conductor/manager.py", line
> >>>>>>> 567, in object_action
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup result = getattr(objinst,
> >>>>>>> objmethod)(context, *args, **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 141,
> >>>>>>> in wrapper
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup return fn(self, ctxt, *args,
> >>>>>>> **kwargs)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup File
> >>>>>>> "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >>>>>>> line
> >>>>>>> 242, in save
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup self._from_db_object(context,
> >>>>>>> self, db_pci)
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup
> >>>>>>> 2013-09-10 12:52:23.774 14749 TRACE
> >>>>>>> nova.openstack.common.threadgroup NameError: global name '_' is
> >>>>>>> not
> >>>>>>> defined
> >>>>>> Can you file a bug for this?
> >>>>>>
> >>>>>> Fix here: https://review.openstack.org/45949
> >>>>>>
> >>>>>> --
> >>>>>> Russell Bryant
> >>>>>
> >>>>>    Thanks, Russell.
> >>>>>
> >>>>>    The bug is reported.
> >>>>> https://bugs.launchpad.net/nova/+bug/1223559
> >>>>>
> >>>>>    But, another error happens after the patch is applied. "TypeError:
> >>>>>    expected string or buffer".
> >>>>>
> >>>>> ----- log message -----
> >>>>>
> >>>>>     File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>>     line 461, in _process_data
> >>>>>       **args)
> >>>>>
> >>>>>     File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >>>>>     line 172, in dispatch
> >>>>>       result = getattr(proxyobj, method)(ctxt, **kwargs)
> >>>>>
> >>>>>     File
> "/usr/lib/python2.6/site-packages/nova/conductor/manager.py",
> >>>>>     line 567, in object_action
> >>>>>       result = getattr(objinst, objmethod)(context, *args, **kwargs)
> >>>>>
> >>>>>     File "/usr/lib/python2.6/site-packages/nova/objects/base.py",
> line
> >>>>>     141, in wrapper
> >>>>>       return fn(self, ctxt, *args, **kwargs)
> >>>>>
> >>>>>     File
> >>>>>     "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >>>>>     line 243, in save
> >>>>>       self._from_db_object(context, self, db_pci)
> >>>>>
> >>>>>     File
> >>>>>     "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py",
> >>>>>     line 150, in _from_db_object
> >>>>>       pci_device.extra_info = jsonutils.loads(extra_info)
> >>>>>
> >>>>>     File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/jsonutils.py",
> >>>>>     line 158, in loads
> >>>>>       return json.loads(s)
> >>>>>
> >>>>>     File "/usr/lib64/python2.6/json/__init__.py", line 307, in loads
> >>>>>       return _default_decoder.decode(s)
> >>>>>
> >>>>>     File "/usr/lib64/python2.6/json/decoder.py", line 319, in decode
> >>>>>       obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> >>>>>
> >>>>> TypeError: expected string or buffer
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup Traceback (most recent call last):
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>>>> line 117, in wait
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup x.wait()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py",
> >>>>> line 49, in wait
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return self.thread.wait()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>>>> 166, in wait
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return self._exit_event.wait()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in
> >>>>> wait
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return hubs.get_hub().switch()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 177,
> >>>>> in switch
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return self.greenlet.switch()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line
> >>>>> 192, in main
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup result = function(*args, **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/service.py",
> >>>>> line 65, in run_service
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup service.start()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/service.py", line 164, in
> >>>>> start
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup self.manager.pre_start_hook()
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> >>>>> 805, in pre_start_hook
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> self.update_available_resource(nova.context.get_admin_context())
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line
> >>>>> 4773, in update_available_resource
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> rt.update_available_resource(context)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py",
> >>>>> line 246, in inner
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return f(*args, **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>> line 318, in update_available_resource
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup self._sync_compute_node(context,
> >>>>> resources)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>> line 347, in _sync_compute_node
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup self._update(context, resources,
> >>>>> prune_stats=True)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py",
> >>>>> line 420, in _update
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup self.pci_tracker.save(context)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/pci/pci_manager.py", line
> >>>>> 126, in save
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup dev.save(context)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 134,
> >>>>> in wrapper
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup ctxt, self, fn.__name__, args,
> >>>>> kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/conductor/rpcapi.py", line
> >>>>> 497, in object_action
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup objmethod=objmethod, args=args,
> >>>>> kwargs=kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 85, in
> >>>>> call
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return
> >>>>> self._invoke(self.proxy.call, ctxt, method, **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 63, in
> >>>>> _invoke
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return cast_or_call(ctxt, msg,
> >>>>> **self.kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/proxy.py",
> >>>>> line 126, in call
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup result = rpc.call(context,
> >>>>> real_topic, msg, timeout)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/__init__.py",
> >>>>> line 139, in call
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return _get_impl().call(CONF,
> >>>>> context, topic, msg, timeout)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py",
> >>>>> line 794, in call
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup rpc_amqp.get_connection_pool(conf,
> >>>>> Connection))
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>> line 574, in call
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup rv = list(rv)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>> line 539, in __iter__
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup raise result
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup TypeError: expected string or
> >>>>> buffer
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup Traceback (most recent call last):
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py",
> >>>>> line 461, in _process_data
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup **args)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> >>>>> line 172, in dispatch
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup result = getattr(proxyobj,
> >>>>> method)(ctxt, **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/conductor/manager.py", line
> >>>>> 567, in object_action
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup result = getattr(objinst,
> >>>>> objmethod)(context, *args, **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 141,
> >>>>> in wrapper
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return fn(self, ctxt, *args,
> >>>>> **kwargs)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py", line
> >>>>> 243, in save
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup self._from_db_object(context,
> >>>>> self, db_pci)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib/python2.6/site-packages/nova/objects/pci_device.py", line
> >>>>> 150, in _from_db_object
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup pci_device.extra_info =
> >>>>> jsonutils.loads(extra_info)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>>
> "/usr/lib/python2.6/site-packages/nova/openstack/common/jsonutils.py",
> >>>>> line 158, in loads
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return json.loads(s)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib64/python2.6/json/__init__.py", line 307, in loads
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup return _default_decoder.decode(s)
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup File
> >>>>> "/usr/lib64/python2.6/json/decoder.py", line 319, in decode
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup obj, end = self.raw_decode(s,
> >>>>> idx=_w(s, 0).end())
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup
> >>>>> 2013-09-10 13:56:35.366 16736 TRACE
> >>>>> nova.openstack.common.threadgroup TypeError: expected string or
> >>>>> buffer
> >>>> Try this:
> >>>>
> >>>> diff --git a/nova/objects/pci_device.py b/nova/objects/pci_device.py
> >>>> index a83b8f3..d0a628a 100644
> >>>> --- a/nova/objects/pci_device.py
> >>>> +++ b/nova/objects/pci_device.py
> >>>> @@ -145,7 +145,7 @@ class PciDevice(base.NovaPersistentObject,
> >>>> base.NovaObject):
> >>>> if key != 'extra_info':
> >>>> pci_device[key] = db_dev[key]
> >>>> else:
> >>>> - extra_info = db_dev.get("extra_info")
> >>>> + extra_info = db_dev.get("extra_info", '{}')
> >>>> pci_device.extra_info = jsonutils.loads(extra_info)
> >>>> pci_device._context = context
> >>>> pci_device.obj_reset_changes()
> >>>>
> >>>>
> >>>> --
> >>>> Russell Bryant
> >>>    The same error happens.
> >>> The error message says "TypeError: expected string or buffer".
> >> hi, David
> >> could you paste the new trace to the bug ? (note it with the patch)
> >> that's close to the fix i think.
> >>
> >> thanks
> >> Yongli he
> >>>    David
> >>>
> >>> _______________________________________________
> >>> 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: 30
> Date: Thu, 12 Sep 2013 07:19:21 +0530
> From: shalz <shalz at hotmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] Comments/questions on the
>         instance-group-api-extension blueprint
> Message-ID: <BLU0-SMTP479F7EBE4906CA8AF96A63DA33A0 at phx.gbl>
> Content-Type: text/plain; charset="us-ascii"
>
> Mike,
>
> You mention  "We are now extending that example to include storage, and we
> are also working examples with Hadoop. "
>
> In the context of your examples / scenarios, do these placement decisions
> consider storage performance and capacity on a physical node?
>
> For example: Based on application needs, and IOPS, latency requirements -
> carving out a SSD storage or a traditional spinning disk block volume?  Or
> say for cost-efficiency reasons using SSD caching on Hadoop name nodes?
>
> I'm investigating  a) Per node PCIe SSD deployment need in Openstack
> environment /  Hadoop environment and ,b) selected node SSD caching,
> specifically for OpenStack Cinder.  Hope this is the right forum to ask
> this question.
>
> rgds,
> S
>
> On Sep 12, 2013, at 12:29 AM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:
>
> > Yes, I've seen that material.  In my group we have worked larger and
> more complex examples.  I have a proposed breakout session at the Hong Kong
> summit to talk about one, you might want to vote for it.  The URL is
> http://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/109and the title is "Continuous Delivery of Lotus Connections on OpenStack".
>  We used our own technology to do the scheduling (make placement decisions)
> and orchestration, calling Nova and Quantum to carry out the decisions our
> software made.  Above the OpenStack infrastructure we used two layers of
> our own software, one focused on infrastructure and one adding concerns for
> the software running on that infrastructure.  Each used its own language
> for a whole topology AKA pattern AKA application AKA cluster.  For example,
> our pattern has 16 VMs running the WebSphere application server, organized
> into four homogenous groups (members are interchangeable) of four each.
>  For each group, we asked that it both (a) be spread across at least two
> racks, with no more than half the VMs on any one rack and (b) have no two
> VMs on the same hypervisor.  You can imagine how this would involve
> multiple levels of grouping and relationships between groups (and you will
> probably be surprised by the particulars).  We also included information on
> licensed products, so that the placement decision can optimize license cost
> (for the IBM "sub-capacity" licenses, placement of VMs can make a cost
> difference).  Thus, multiple policies per thing.  We are now extending that
> example to include storage, and we are also working examples with Hadoop.
> >
> > Regards,
> > Mike
> >
> >
> >
> > From:        Gary Kotton <gkotton at vmware.com>
> > To:        OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>,
> > Date:        09/11/2013 06:06 AM
> > Subject:        Re: [openstack-dev] [heat] Comments/questions on the
> instance-group-api-extension blueprint
> >
> >
> >
> >
> >
> > From: Mike Spreitzer <mspreitz at us.ibm.com>
> > Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> > Date: Tuesday, September 10, 2013 11:58 PM
> > To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [heat] Comments/questions on the
> instance-group-api-extension blueprint
> >
> > First, I'm a newbie here, wondering: is this the right place for
> comments/questions on blueprints?  Supposing it is...
> >
> > [Gary Kotton] Yeah, as Russel said this is the correct place
> >
> > I am referring to
> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
> >
> > In my own research group we have experience with a few systems that do
> something like that, and more (as, indeed, that blueprint explicitly states
> that it is only the start of a longer roadmap).  I would like to highlight
> a couple of differences that alarm me.  One is the general overlap between
> groups.  I am not saying this is wrong, but as a matter of natural
> conservatism we have shied away from unnecessary complexities.  The only
> overlap we have done so far is hierarchical nesting.  As the
> instance-group-api-extension explicitly contemplates groups of groups as a
> later development, this would cover the overlap that we have needed.  On
> the other hand, we already have multiple "policies" attached to a single
> group.  We have policies for a variety of concerns, so some can combine
> completely or somewhat independently.  We also have relationships (of
> various sorts) between groups (as well as between individuals, and between
> individuals and groups).  The policies and relationships, in general, are
> not simply names but also have parameters.
> >
> > [Gary Kotton] The instance groups was meant to be the first step towards
> what we had presented in Portland. Please look at the presentation that we
> gave an this may highlight what the aims were:
> https://docs.google.com/presentation/d/1oDXEab2mjxtY-cvufQ8f4cOHM0vIp4iMyfvZPqg8Ivc/edit?usp=sharing.
> Sadly for this release we did not manage to get the instance groups through
> (it was an issue of timing and bad luck). We will hopefully get this though
> in the first stages of the I cycle and then carry on building on it as it
> has a huge amount of value for OpenStack. It will be great if you can also
> participate in the discussions.
> >
> > Thanks,
> > Mike_______________________________________________
> > 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/20130912/f0cc60ca/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 31
> Date: Thu, 12 Sep 2013 13:25:26 +1000
> From: Jamie Lennox <jlennox at redhat.com>
> To: OpenStack-dev at lists.openstack.org
> Subject: [openstack-dev] [Keystone] Enforcing cert validation in
>         auth_token      middleware
> Message-ID: <1378956326.20243.22.camel at dhcp-40-102.bne.redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
> With the aim of replacing httplib and cert validation with requests[1]
> I've put forward the following review to use the requests library for
> auth_token middleware.
>
> https://review.openstack.org/#/c/34161/
>
> This adds 2 new config options.
> - The ability to provide CAs to validate https connections against.
> - The ability to set insecure to ignore https validation.
>
> By default request will validate connections against the system CAs by
> default. So given that we currently don't verify SSL connections, do we
> need to default insecure to true?
>
> Maintaining compatibility should win here as i imagine there are a great
> number of auth_token deployments using SSL with invalid/self-signed
> certificates that would be broken, but defaulting to insecure just seems
> wrong.
>
> Given that keystone isn't the only project moving away from httplib, how
> are other projects handling this? How do we end up with reasonable
> defaults? Is there any amount of warning that we could give to change a
> default like this - or is this another one of those version 1.0 issues?
>
>
> Jamie
>
>
>
> [1] https://bugs.launchpad.net/keystone/+bug/1188189
>
>
>
>
> ------------------------------
>
> Message: 32
> Date: Wed, 11 Sep 2013 22:46:12 -0500
> From: Dolph Mathews <dolph.mathews at gmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Keystone] Enforcing cert validation in
>         auth_token middleware
> Message-ID:
>         <CAC=h7gUkyk_F4oZivSSN2A=CQw3G3=
> WoB0X2HYWOLpvYJ_NMFQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, Sep 11, 2013 at 10:25 PM, Jamie Lennox <jlennox at redhat.com> wrote:
>
> > With the aim of replacing httplib and cert validation with requests[1]
> > I've put forward the following review to use the requests library for
> > auth_token middleware.
> >
> > https://review.openstack.org/#/c/34161/
> >
> > This adds 2 new config options.
> > - The ability to provide CAs to validate https connections against.
> > - The ability to set insecure to ignore https validation.
> >
> > By default request will validate connections against the system CAs by
> > default. So given that we currently don't verify SSL connections, do we
> > need to default insecure to true?
> >
>
> I vote no; and yes to "secure by default."
>
>
> >
> > Maintaining compatibility should win here as i imagine there are a great
> > number of auth_token deployments using SSL with invalid/self-signed
> > certificates that would be broken, but defaulting to insecure just seems
> > wrong.
> >
> > Given that keystone isn't the only project moving away from httplib, how
> > are other projects handling this?
>
>
> The last time keystoneclient made this same change (thanks Dean!), we
> provided no warning:
>
>   https://review.openstack.org/#/c/17624/
>
> Which added the --insecure flag to opt back into the old behavior.
>
> How do we end up with reasonable
> > defaults? Is there any amount of warning that we could give to change a
> > default like this - or is this another one of those version 1.0 issues?
> >
> >
> > Jamie
> >
> >
> >
> > [1] https://bugs.launchpad.net/keystone/+bug/1188189
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
>
> -Dolph
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/cc73b1a3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 33
> Date: Thu, 12 Sep 2013 11:50:42 +0800
> From: "lzy.dev at gmail.com" <lzy.dev at gmail.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] FFE Request: image-multiple-location
>         support
> Message-ID:
>         <
> CAN__O6uSWFpCCaofycDKgkEFwBNQkRKS2hM1Ap8MOLKJ0oZXYw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Folks,
>
> BP: https://blueprints.launchpad.net/nova/+spec/image-multiple-location
>
> Since a dependent patch getting merger delay
> (https://review.openstack.org/#/c/44316/), so the main patch
> https://review.openstack.org/#/c/33409/ been hold by FF. It's very
> close to get merger and waited about 3 months, could you pls take a
> look and let it go in H?
>
> thanks,
> zhiyan
>
>
>
> ------------------------------
>
> Message: 34
> Date: Thu, 12 Sep 2013 04:15:39 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
>         <openstack-dev at lists.openstack.org>, Keith Bray
>         <keith.bray at RACKSPACE.COM>
> Subject: Re: [openstack-dev] [Heat] How the autoscale API should
>         control scaling in Heat
> Message-ID: <CE568CE3.47930%harlowja at yahoo-inc.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ah, thx keith, that seems to make a little more sense with that context.
>
> Maybe that different instance will be doing other stuff also?
>
> Is that the general heat 'topology' that should/is recommended for trove?
>
> For say autoscaling trove, will trove emit a set of metrics via ceilometer
> that heat (or a separate autoscaling thing) will use to analyze if
> autoscaling should occur? I suppose nova would also emit its own set and
> it will be up to the autoscaler to merge those together (as trove
> instances are nova instances). Its a very interesting set of problems to
> make an autoscaling entity that works well without making that autoscaling
> entity to aware of the internals of the various projects. Making it to
> aware and then the whole system is fragile but not making it aware enough
> and then it will not do its job very well.
>
> On 9/11/13 6:07 PM, "Keith Bray" <keith.bray at RACKSPACE.COM> wrote:
>
> >There is context missing here.  heat==>trove interaction is through the
> >trove API.  trove==>heat interaction is a _different_ instance of Heat,
> >internal to trove's infrastructure setup, potentially provisioning
> >instances.   Public Heat wouldn't be creating instances and then telling
> >trove to make them into databases.
> >
> >At least, that's what I understand from conversations with the Trove
> >folks.  I could be wrong here also.
> >
> >-Keith
> >
> >On 9/11/13 11:11 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
> >
> >>Sure,
> >>
> >>I was thinking that since heat would do autoscaling persay, then heat
> >>would say ask trove to make more databases (autoscale policy here) then
> >>this would cause trove to actually callback into heat to make more
> >>instances.
> >>
> >>Just feels a little weird, idk.
> >>
> >>Why didn't heat just make those instances "on behalf of trove" to begin
> >>with and then tell trove "make these instances into databases". Then
> >>trove doesn't really need to worry about calling into heat to do the
> >>instance creation "work", and trove can just worry about converting those
> >>"blank instances " into databases (for example).
> >>
> >>But maybe I am missing other context also :)
> >>
> >>Sent from my really tiny device...
> >>
> >>On Sep 11, 2013, at 8:04 AM, "Clint Byrum" <clint at fewbar.com> wrote:
> >>
> >>> Excerpts from Joshua Harlow's message of 2013-09-11 01:00:37 -0700:
> >>>> +1
> >>>>
> >>>> The assertions are not just applicable to autoscaling but to software
> >>>>in general. I hope we can make autoscaling "just enough" simple to
> >>>>work.
> >>>>
> >>>> The circular heat<=>trove example is one of those that does worry me a
> >>>>little. It feels like something is not structured right if that it is
> >>>>needed (rube goldberg like). I am not sure what could be done
> >>>>differently, just my gut feeling that something is "off".
> >>>
> >>> Joshua, can you elaborate on "the circular heat<=>trove example"?
> >>>
> >>> I don't see Heat and Trove's relationship as circular. Heat has a Trove
> >>> resource, and (soon? now?) Trove can use Heat to simplify its control
> >>> of underlying systems. This is a stack, not a circle, or did I miss
> >>> something?
> >>>
> >>> _______________________________________________
> >>> 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
>
>
>
>
> ------------------------------
>
> _______________________________________________
> 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 17, Issue 16
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130912/7c91d7b0/attachment-0001.html>