[openstack-dev] [Fuel][Plugin]Add multiple backends support

Wang, Peter (Xu) Peter.Wang13 at dell.com
Fri Oct 21 14:09:53 UTC 2016


I also have the same requirement for Fuel UI.

Agree that we need the capability in Fuel UI framework to manage multiple groups of data, the data usually have same fields/structure

These data could not be able to simple separated by "comma", since this is error-prone for both administrators and plugin developers

My suggestion is to introduce "table grid" to manage "groups" of data, and user can edit detail info for each of line in a pop up window
A add/remove button can be added around the "table grid"
You can refer to adding a controller/cinder node from fuel UI.

For each plugin, they handle the table data like below:
----------------------
For line in lines:
   Process line......

End
---------------------

Any thoughts?

Thanks
Peter

-----Original Message-----
From: openstack-dev-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org] 
Sent: Friday, October 21, 2016 8:00 PM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 54, Issue 52

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: Endpoint structure: a free-for-all (joehuang)
   2. [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 21 2016
      (hu.zhijiang at zte.com.cn)
   3. Participate in a Usability Study at Barcelona: Get a free
      bluetooth speaker and OpenStack t-shirt for your time
      (Kruithof Jr, Pieter)
   4. What do customers want?: Six studies conducted by the
      OpenStack UX project on behalf of the community (Kruithof Jr, Pieter)
   5. Re: [heat] Rolling Upgrades (Rabi Mishra)
   6. [OpenStack-dev][Fuel][Plugin] (nidhi.hada at wipro.com)
   7. Re: [api] [nova] microversion edge case query (Alex Xu)
   8. [Congress] IRC during summit (Eric K)
   9. Re: [neutron][calico][tempest][gate] Help setting up DSVM
      gate job for networking-calico (Kevin Benton)
  10. Re: [vitrage][aodh] about aodh notifier to create a event
      alarm (Afek, Ifat (Nokia - IL))
  11. Re: [release][ptl] pausing releases until 1 Nov (Julien Danjou)
  12. Re: [glance][VMT][Security] Glance coresec reorg (Flavio Percoco)
  13. Re: [neutron][calico][tempest][gate] Help setting up DSVM
      gate job for networking-calico (Neil Jerram)
  14. [Keystone][Design Session] Where to propose	extensions to
      trusts? (Johannes Grassler)
  15. [daisycloud-core] Meeting minutes for IRC meeting 0800UTC
      Oct. 21 2016 (hu.zhijiang at zte.com.cn)
  16. Re: [OpenStack-dev][Fuel][Plugin] (Julia Aranovich)
  17. [all] Automation and self described APIs (Gilles Dubreuil)
  18. Re: Does it make sense to have self links to things that
      don't exist? (Chris Dent)
  19. [nova][cinder] Addressing mangled LUKS passphrases
      (bug#1633518) (Lee Yarwood)
  20. Re: Endpoint structure: a free-for-all (Chris Dent)
  21. Re: [all] indoor climbing break at summit? (Chris Dent)
  22. Re: Endpoint structure: a free-for-all (Doug Hellmann)
  23. Re: [api] [nova] microversion edge case query (Chris Dent)


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

Message: 1
Date: Fri, 21 Oct 2016 02:42:14 +0000
From: joehuang <joehuang at huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID:
	<5E7A3D1BF5FD014E86E5F971CF446EFF559BC5E6 at szxema505-mbx.china.huawei.com>
	
Content-Type: text/plain; charset="us-ascii"

Hi,

I recalled one issue during using endpoint structure in public cloud
based on OpenStack.

Currently each service listens on its own port, the format of the endpoint
is like: service-specific ports, e.g., https://cloud.com:1234/v2

If the end user want to access Nova/Cinder/Neutron service endpoint
directly, for example using curl or other tools, then these ports 8774, 8776, 9696 have to be
exposed to the end user. Then you have to open these ports
in many devices if you want to provide these services in the public cloud directly to
end user. The more services are added to the public cloud, the more have to be
configured in these devices for security purpose.

>From public cloud point of view, the port 80 will be opened by default, but if you have
to open so many non-80 ports, it brings additional work and challenge to manage these ports,
especially in firewalls, anti-DDoS, etc.

So I think that it would be better to use sub-domain or path to expose different
services end-point. 

A. subdomains, e.g., https://service.cloud.com/v2
 B. paths, e.g., https://cloud.com/service/v2 

Best Regards
Chaoyi Huang (joehuang)

________________________________________
From: Brian Curtin [brian at python.org]
Sent: 19 October 2016 23:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Endpoint structure: a free-for-all

I'm currently facing what looks more and more like an impossible
problem in determining the root of each service on a given cloud. It
is apparently a free-for-all in how endpoints can be structured, and I
think we're out of ways to approach it that catch all of the ways that
all people can think of.

In openstacksdk, we can no longer use the service catalog for
determining each service's endpoints. Among other things, this is due
to a combination of some versions of some services not actually being
listed, and with things heading the direction of version-less services
anyway. Recently we changed to using the service catalog as a pointer
to where services live and then try to find the root of that service
by stripping the path down and making some extra requests on startup
to find what's offered. Despite a few initial snags, this now works
reasonably well in a majority of cases.

We have seen endpoints structured in the following ways:
 A. subdomains, e.g., https://service.cloud.com/v2
 B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
more paths in between the root and /service/)
 C. service-specific ports, e.g., https://cloud.com:1234/v2
 D. both A and B plus ports

Within all of these, we can find the root of the given service just
fine. We split the path and build successively longer paths starting
from the root. In the above examples, we need to hit the path just
short of the /v2, so in B it actually takes two requests as we'd make
one to cloud.com which fails, but then a second one to
cloud.com/service gives us what we need.

However, another case came up: the root of all endpoints is itself
another service. That makes it look like this:

 E. https://cloud.com:9999/service/v2
 F. https://cloud.com:9999/otherservice

In this case, https://cloud.com:9999 is keystone, so trying to get E's
base by going from the root and outward will give me a versions
response I can parse properly, but it points to keystone. We then end
up building requests for 'service' that go to keystone endpoints and
end up failing. We're doing this using itertools.accumulate on the
path fragments, so you might think 'just throw it through
`reversed()`' and go the other way. If we do that, we'll also get a
versions response that we can parse, but it's the v2 specific info,
not all available versions.

So now that we can't reliably go from the left, and we definitely
can't go from the right, how about the middle?

This sounds ridiculous, and if it sounds familiar it's because they
devise a "middle out" algorithm on the show Silicon Valley, but in
most cases it'd actually work. In E above, it'd be fine. However,
depending on the number of path fragments and which direction we chose
to move first, we'd sometimes hit either a version-specific response
or another service's response, so it's not reliable.

Ultimately, I would like to know how something like this can be solved.

1. Is there any reliable, functional, and accurate programmatic way to
get the versions and endpoints that all services on a cloud offer?

2. Are there any guidelines, rules, expectations, or other
documentation on how services can be installed and their endpoints
structured that are helpful to people build apps that use them, not in
those trying to install and operate them? I've looked around a few
times and found nothing useful. A lot of what I've found has
referenced suggestions for operators setting them up behind various
load balancing tools.

3. If 1 and 2 won't actually help me solve this, do you have any other
suggestions that will? We already go left, right, and middle of each
URI, so I'm out of directions to go, and we can't go back to the
service catalog.

Thanks,

Brian

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



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

Message: 2
Date: Fri, 21 Oct 2016 11:12:14 +0800
From: hu.zhijiang at zte.com.cn
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [daisycloud-core] Agenda for IRC meeting
	0800UTC Oct. 21 2016
Message-ID:
	<OF5F3A0595.970F811C-ON48258053.001178BE-48258053.00118AD1 at zte.com.cn>
Content-Type: text/plain; charset="US-ASCII"

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction
5) Newton Release Related

B.R.,
Zhijiang




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

Message: 3
Date: Fri, 21 Oct 2016 03:20:01 +0000
From: "Kruithof Jr, Pieter" <pieter.kruithof.jr at intel.com>
To: "openstack-dev at lists.openstack.org"
	<openstack-dev at lists.openstack.org>
Cc: "openstack-operators at lists.openstack.org"
	<openstack-operators at lists.openstack.org>,
	"user-committee at lists.openstack.org"
	<user-committee at lists.openstack.org>
Subject: [openstack-dev] Participate in a Usability Study at
	Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your
	time
Message-ID: <60FF081C-DBD5-49A7-B624-B2F7583E6D1E at intel.com>
Content-Type: text/plain; charset="utf-8"

Apologies for any cross-postings.


Hi Folks,

I wanted to send a second notice that there will be two usability studies being conducted in Barcelona with cloud operators. We had nearly a 100% show rate last summit and the results had a direct impact on the OpenStackClient.  In fact, the results were shared at the OSC working session the next day.

Intel is providing a Philips bluetooth speaker to show our appreciation for your time.  In addition, the foundation is providing a t-shirt to each person that participates in the study. I may even give anyone suffering from jetlag a Red Bull to get them through the day.

___
The first study will be on Monday, October 24th and is intended to investigate the current APIs to understand any specific pain points associated with completing tasks that span projects such as quotas.  This study will last 45 minutes per operator.

You can schedule a time here:

http://doodle.com/poll/fwfi2sfcuctxv3u8

Note that you may need to set the time zone in Doodle to Spain > Ceuta

___
The second study will be on Tuesday, October 25th and is intended to investigate the OpenStackClient to understand any specific pain points and opportunities associated with completing tasks with the client.  This study will last 45 minutes per operator.  We ran a similar study at the previous summit and the feedback from users was that it was a good opportunity to ?test drive? the client with an OSC expert in the room with them.

You can schedule a time here:

http://doodle.com/poll/894aqsmheaa2mv5a

Note that you may need to set the time zone in Doodle to Spain > Ceuta


For both studies, someone with the OpenStack UX project will send you a calendar invite after you select a time(s) that are convenient for you.


Thanks,


Piet Kruithof
PTL OpenStack UX

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

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

Message: 4
Date: Fri, 21 Oct 2016 03:20:30 +0000
From: "Kruithof Jr, Pieter" <pieter.kruithof.jr at intel.com>
To: "openstack-dev at lists.openstack.org"
	<openstack-dev at lists.openstack.org>,
	"openstack-operators at lists.openstack.org"
	<openstack-operators at lists.openstack.org>
Subject: [openstack-dev] What do customers want?: Six studies
	conducted by the OpenStack UX project on behalf of the community
Message-ID: <E0DA5CA7-83E2-44B9-875D-7A6296614876 at intel.com>
Content-Type: text/plain; charset="utf-8"

Hi Folks,

The OpenStack UX project and Intel have produced three booklets for the Barcelona OpenStack Summit based on the OpenStack UX?s work over the past six months.

The first is an overview of user research that was conducted on behalf of the OpenStack community including operator information needs, novice user experience for Horizon, OpenStackClient (OSC) validation and managing quotas at scale.

https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing

The second booklets include the OpenStack Personas and GUI Guidelines:

OpenStack Personas:
https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing

OpenStack GUI Guidelines:
https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing


___
Unfortunately, we were unable to include the results for the searchlight/horizon integration as well as cloud architect information needs.  However, the presentations are posted to the OpenStack UX YouTube channel.

https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw

The channel is updated regularly, so it may be worth checking from time to time.


___
For extra credit, my suggestion would be to read the ?State of OpenStack User Experience October 2016? which provides a succinct overview of the research that was conducted, why it matters, results, and recommendations.

https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing



Thanks,

Piet Kruithof
PTL OpenStack UX project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/a395ede6/attachment-0001.html>

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

Message: 5
Date: Fri, 21 Oct 2016 10:00:07 +0530
From: Rabi Mishra <ramishra at redhat.com>
To: cwolfe at redhat.com,  "OpenStack Development Mailing List (not for
	usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] Rolling Upgrades
Message-ID:
	<CABJHmF7E+hZJs1YHZ-QMk8n5R+Jxr8Xjzm=v9qTTK6TtzQed6w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks Crag on starting the thread. Few comments inline.

On Fri, Oct 21, 2016 at 5:32 AM, Crag Wolfe <cwolfe at redhat.com> wrote:

> At Summit, folks will be discussing the rolling upgrade issue across a
> couple of sessions. I personally won't be able to attend, but thought
> I would share my thoughts on the subject.
>
> To handle rolling upgrades, there are two general cases to consider:
> database model changes and RPC method signature changes.
>
> For DB Model changes (this has already been well discussed on the
> mailing list, see the footnotes), let's assume for the moment we don't
> want to use triggers. If we are moving data from one column/table to
> another, the pattern looks like:
>
> legacy release: write to old location
> release+1: write to old and new location, read from old
> release+2: write to old and new location, read from new,
>            provide migration utility
> release+3: write to new location, read from new
>
Not sure I understand this. Is it always about changing the table name or
column name of a table?
What about adding a new column to an existing table? I assume the db api
implementation have to ignore the additional column values when writing to
old location.


> Works great! The main issue is if the duplicated old and new data
> happens to be large. For a heat-specific example (one that is close to
> my heart), consider moving resource/event properties data into a
> separate table.
>
> We could speed up the process by adding config variables that specify
> where to read from, but that is putting a burden on the operator,
> creating a risk that data is lost if the config variables are not
> updated in the correct order after each full rolling restart, etc.
>
> Which brings us back to triggers. AFAIK, only sqlalchemy+mariadb is
> being used in production, so we really only have one backend we would
> have to write triggers for. If the data duplication is too unpalatable
> for a given migration (using the +1, +2, +3 pattern above), we may
> have to wade into the less simple world of triggers.
>
I think we can only enable the trigger during the upgrade process and then
disable it.


> For RPC changes, we don't have a great solution right now (looking
> specifically at heat/engine/service.py). If we add a field, an older
> running heat-engine will break if it receives a request from a newer
> running heat-engine. For a relevant example, consider adding the
> "root_id" as an argument (
> https://review.openstack.org/#/c/354621/13/heat/engine/service.py ).
>
> Looking for the simplest solution -- if we introduce a mandatory
> "future_args" arg (a dict) now to all rpc methods (perhaps provide a
> decorator to do so), then we could follow this pattern post-Ocata:
>
> legacy release: accepts the future_args param (but does nothing with it).
> release+1: accept the new parameter with a default of None,
>            pass the value of the new parameter in future_args.
> release+2: accept the new parameter, pass the value of the new parameter
>            in its proper placeholder, no longer in future_args.
>
This is something similar to the one is being used by neutron for the
agents,
i.e consistently capturing those new/unknown arguments with keyword
arguments
and ignoring them on agent side; and by not enforcing newer RPC entry point
versions on server side. However,  this makes the rpc api less strict and
not ideal.

The best way would be do some kind of rpc pinning on the new engines when
they send messages(new engines can receive old messages). I was also
wondering
if it's possible/good idea to restrict engines not to communicate with
other engines
only during the upgrade process.

But, we don't have a way of deleting args. That's not super
> awful... old args never die, they just eventually get ignored. As for
> adding new api's, the pattern would be to add them in release+1, but
> not call them until release+2. [If we really have a case where we need
> to add and use a new api in release+1, the solution may be to have two
> rpc api messaging targets in release+1, one for the previous
> major.minor release and another for the major+1.0 release that has the
> new api. Then, we of course we could remove outdated args in
> major+1.0.]
>
I'm not sure we ever delete args, as we make the rpc servers backward
compatible.


> Finally, a note about Oslo versioned objects: they don't really help
> us. They work great for nova where there is just nova-conductor
> reading and writing to the DB, but we have multiple heat-engines doing
> that that need to be restarted in a rolling manner. See the references
> below for greater detail.
>
> --Crag
>
> References
> ----------
>
> [openstack-dev] [Heat] Versioned objects upgrade patterns
> http://lists.openstack.org/pipermail/openstack-dev/2016-
> May/thread.html#95245
>
> [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades:
> database triggers and oslo.versionedobjects
> http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/102698.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-
> October/105764.html
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/9c5274fc/attachment-0001.html>

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

Message: 6
Date: Fri, 21 Oct 2016 05:16:08 +0000
From: <nidhi.hada at wipro.com>
To: <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
Message-ID:
	<SIXPR0301MB13386D15FF13B35C13865D0486D40 at SIXPR0301MB1338.apcprd03.prod.outlook.com>
	
Content-Type: text/plain; charset="iso-8859-1"

Hi All,


This is regarding an info required for fuel plugin development.

We are working on Fuel Cinder Plugin where we require to

configure multiple 'n' number of backends of storage vendor ,

in one go, from Fuel UI screen. where 'n' will be known at run time.


Its like from UI, I can configure a set of fields, [field1, field2, field3]

for one backend and if user ask to configure 'n' backends then same

set of fields to be asked repeatedly.


I have found some similar provision was planned in

https://blueprints.launchpad.net/fuel/+spec/dynamic-fields


But when i see implementation https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z

which implements new type as text_list and textarea_list ..

which is capability to add multiple lines of text in single field..


It does not look like same as aim of BP, where acceptance criteria for BP is

"Enable text and textarea field types to be extended - where a plugin user is able to toggle the visibility of additional fields with +/- signs and the data provided is used by plugin"


Kindly correct my understanding if its wrong, do we have capability to add a text field by pressing +/- ?

What capability do we have with Fuel UI to add fields dynamically today ?


I have read https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel

[openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI - OpenStack Mailing List Archive<https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel>
openstack.nimeyo.com
Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp (to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



where suggestions are made to use restrictions to hide display components.


Another suggestion is to use comma separated values.


But its an year back post, do we have a better solution today ?


Will be helpful if someone can suggest how do we achieve it in fuel UI.



Thanks

Nidhi







The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/f7954eeb/attachment-0001.html>

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

Message: 7
Date: Fri, 21 Oct 2016 14:20:39 +0800
From: Alex Xu <soulxu at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
Message-ID:
	<CAH7mGauaFBeGt9njyBfg2Y840exN6i_3FdJS0p+K91yLrBAU_Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2016-10-19 0:58 GMT+08:00 Ed Leafe <ed at leafe.com>:

> On Oct 18, 2016, at 11:01 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> >
> > If the requested microversion is greater than the maximum, a 404 still
> > makes some sense (no mapping _now_), but a 406 could as well because it
> > provides a signal that if you used a different microversion the
> > situation could be different and the time represented by the
> > requested microversion has conceptual awareness of its past.
> >
> > What do people think?
> >
> > I think I recall there was some discussion of this sort of thing
> > with regard to some of the proxy APIs at the nova midcycle but I
> > can't remember the details of the outcome.
>
> The only way that that could happen (besides a total collapse of the
> review process) is when a method is removed from the API. When that
> happens, the latest version has its max set to the last microversion where
> that method is supported. For microversions after that, 404 is the correct
> response. For all other methods, the latest version should not have a
> maximum specified.
>


Also think 404 is right at here. If you return 406 and it is a signal that
if you used a different microversion the situation could be different, the
thing will become strange when we raise the acceptable min_version someday.



>
> -- Ed Leafe
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/6cff826b/attachment-0001.html>

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

Message: 8
Date: Fri, 21 Oct 2016 00:03:21 -0700
From: Eric K <ekcs.openstack at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Congress] IRC during summit
Message-ID: <D42F04D8.3F4BA%ekcs.openstack at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi all!

To help us connect and coordinate during the upcoming summit, those who are
interested can try IRCcloud (https://www.irccloud.com ; suggested by aimeeu)
to communicate over the #congress channel. The service acts as an IRC
bouncer to keep your nick connected and send push notifications to the
mobile app. I just tried it out and it works pretty well.

To be notified of all messages on the channel, set your mobile app to
?Notify on all messages? (under display options). To be notified only of
messages that mention your nick, just keep the default settings.

See you all at the summit soon!


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

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

Message: 9
Date: Fri, 21 Oct 2016 00:05:27 -0700
From: Kevin Benton <kevin at benton.pub>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][calico][tempest][gate] Help
	setting up DSVM gate job for networking-calico
Message-ID:
	<CAO_F6JM9efO-=nDb+fOzYCg0ogDOL_D1_9XCPmaSr39Ombk4Yg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Left a comment on your patch. Looks like you have tempest disabled in your
devstack settings file.

On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram <neil at tigera.io> wrote:

> I'm trying to set up a dsvm gate job for networking-calico [1] - which I
> think means
> - using DevStack to set up a single combined controller/compute node, with
> networking-calico settings and plugin [2]
> - using Tempest to run some tests on that; ideally including some
> networking-related tests :-)
>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because
> of something to do with credentials, and that also seem unrelated to
> networking, and I'm not sure if any networking-related tests are running.
>
> I've tried comparing against the similar job for networking-ovn [5][6].
> Before the point where Tempest starts reporting success/failure of
> individual tests, the only notable difference I see is that the
> networking-calico output has:
>
> sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
> directory
> Running tempest with a custom regex filter
> all create: /opt/stack/new/tempest/.tox/tempest
> all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
> all develop-inst: /opt/stack/new/tempest
>
> where the networking-ovn output only has:
>
> Running tempest with a custom regex filter
> all develop-inst-noop: /opt/stack/new/tempest
>
> Is that significant?
>
> Then the next, very obvious, difference is that the networking-calico
> output seems to have the results of individual tests all jumbled up - like
> output from multiple threads without a lock:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpGuFAar
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> {0} setUpClass (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery)
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class
> 'tempest.lib.exceptions.InvalidCredentials'> raised in
> AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
> {3} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative)
> ... SKIPPED: TestPortsNegative skipped as Ironic is not available
> 20{3} setUpClass (tempest.api.baremetal.admin.test_nodestates.TestNodeStates)
> ... SKIPPED: TestNodeStates skipped as Ironic is not available
> 16{0} setUpClass (tempest.api.compute.admin.test_agents.AgentsAdminTestJSON)
> [0.000000s] ... FAILED
> 2{3} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
> (tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
> TestChassis skipped as Ironic is not available
> 23:3020.41356 7-9 0931300006 INFO tempest.test [-] <class
> 'tempest.lib.exceptions.InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22
> t. [i3-8aIN]l6 FOs  t'30em90<p>4 IN class resFa't.O teitesmpstt
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
> 'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn Agitgeber.
> aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv
>
> whereas the networking-ovn output looks neat:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> {0} setUpClass (tempest.api.baremetal.admin.test_nodestates.TestNodeStates)
> ... SKIPPED: TestNodeStates skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery)
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> {3} setUpClass (tempest.api.baremetal.admin.test_chassis.TestChassis) ...
> SKIPPED: TestChassis skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative)
> ... SKIPPED: TestPortsNegative skipped as Ironic is not available
> {1} setUpClass (tempest.api.compute.admin.test_baremetal_nodes.BaremetalNodesAdminTestJSON)
> ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_using_string_ram
> [0.232261s] ... ok
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_flavor_verify_entry_in_list_details [0.101537s] ... ok
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_int_id
> [0.081664s] ... ok
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_none_id
> [0.079674s] ... ok
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_uuid_id
> [0.075899s] ... ok
> {1} tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_
> create_list_flavor_without_extra_data [0.409597s] ... ok
>
> I would appreciate any help as regards what I'm doing wrong here.
>
> Thanks,
>      Neil
>
> [1] http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/jenkins/jobs/networking-calico.yaml
> [2] http://git.openstack.org/cgit/openstack/networking-calico/
> tree/devstack
> [3] https://review.openstack.org/#/c/339263/
> [4] http://logs.openstack.org/63/339263/5/experimental/gate-
> tempest-dsvm-networking-calico-nv/8d47b1c/console.html
> [5] http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/jenkins/jobs/networking-ovn.yaml
> [6] http://logs.openstack.org/16/386016/1/check/gate-tempest-
> dsvm-networking-ovn/4e3924f/console.html.gz
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/12558dc1/attachment-0001.html>

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

Message: 10
Date: Fri, 21 Oct 2016 07:21:51 +0000
From: "Afek, Ifat (Nokia - IL)" <ifat.afek at nokia.com>
To: "dong.wenjuan at zte.com.cn" <dong.wenjuan at zte.com.cn>, gordon chung
	<gord at live.ca>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to
	create a event alarm
Message-ID: <AA498EFB-1739-43B4-8021-89DCEC588DC3 at alcatel-lucent.com>
Content-Type: text/plain; charset="utf-8"

dwj,

This would be great! Thanks for your help.

Ifat.

From: "dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn>"
Date: Friday, 21 October 2016 at 04:14
To: "Afek, Ifat (Nokia - IL)", gordon chung
Cc: "OpenStack Development Mailing List (not for usage questions)"
Subject: ??: Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm


Hi All,

I think it's clear now.
We can start to implement  the Aodh-message-bus-notificationsBP. :)
Thanks~

BR,
dwj





"Afek, Ifat (Nokia - IL)" <ifat.afek at nokia.com<mailto:ifat.afek at nokia.com>>

2016-10-21 01:23


???
        gordon chung <gord at live.ca<mailto:gord at live.ca>>, "dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn>" <dong.wenjuan at zte.com.cn<mailto:dong.wenjuan at zte.com.cn>>
??
        "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
??
        Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm












On 20/10/2016, 20:14, "gordon chung" <gord at live.ca<mailto:gord at live.ca>> wrote:

>
>On 20/10/16 01:01 PM, Afek, Ifat (Nokia - IL) wrote:
>> Well? long time ago I asked to add another notification topic to Aodh, and you said that you blocked it. If that?s not the case, everything is fine :-)
>> Like I said before, we planned on implementing it in Newton, but unfortunately it didn?t happen. I really hope to improve the Vitrage-Aodh integration in Ocata.
>>
>>
>>
>> Ifat.
>
>i see. i wasn't being critical about no work but i'll be honest, i don't
>remember what this is about since i was looking at other stuff so if you
>have a patch/ML to refresh my memory, that'd help.
>
>this is the only thread[1] i recall, and even then, i don't remember
>much about it. :(
>
>[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098074.html
>
>cheers,
>
>--
>gord

What I recall was a few months earlier, we had a chat on ceilometer IRC channel? not sure if I can find the exact date.
Anyway, I guess it doesn?t matter now. If you think the change can be done, then great.

Ifat.



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

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

Message: 11
Date: Fri, 21 Oct 2016 09:40:51 +0200
From: Julien Danjou <julien at danjou.info>
To: Emilien Macchi <emilien at redhat.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [release][ptl] pausing releases until 1
	Nov
Message-ID: <m0lgxib14s.fsf at danjou.info>
Content-Type: text/plain; charset="us-ascii"

On Thu, Oct 20 2016, Emilien Macchi wrote:

> I take this opportunity to thank doug/dims/ttx for their hard work on
> release management; they always help PTLs in a productive and
> responsive way to reach the goals.
> As a PTL, I always feel happy to deal with release management assisted
> by such a great team, with nice tools like reno and openstack/releases
> repo.

Ditto.

Also I'd like to emphasize how happy I become dealing with the
openstack/releases repository even and especially for independent
projects, where nothing peculiar has been implemented. :-)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/cb62103b/attachment-0001.pgp>

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

Message: 12
Date: Fri, 21 Oct 2016 10:07:12 +0200
From: Flavio Percoco <flavio at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [glance][VMT][Security] Glance coresec
	reorg
Message-ID: <20161021080712.lpr3xhkupwrbbvmx at redhat.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 20/10/16 12:33 -0700, Steve Lewis wrote:
>I'm not voicing as a core here, but in the course of several cycles I have
>seen Erno and Ian each providing the care and insight needed by this role
>and trust them to do the job well.
>

+1k to the above!

Thank you both for stepping up for this critical task.
Flavio

>
>On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
>> On 2016-10-18 22:22:28 +0000 (+0000), Brian Rosmaita wrote:
>> > Thus, the main point of this email is to propose Ian Cordasco and Erno
>> > Kuvaja as new members of the Glance coresec team.  They've both been
>> > Glance cores for several cycles, have a broad knowledge of the software
>> > and team, contribute high-quality reviews, and are conversant with good
>> > security practices.
>> [...]
>>
>> Sounds good to me. From a VMT perspective, I'm just happy to see
>> Glance keeping active participants with available bandwidth looking
>> at prospective vulnerability reports so we can continue to churn
>> through them faster and make them public sooner. Thanks for keeping
>> the wheels turning!
>> --
>> Jeremy Stanley
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>-- 
>SteveL

>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/131e9b81/attachment-0001.pgp>

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

Message: 13
Date: Fri, 21 Oct 2016 08:51:06 +0000
From: Neil Jerram <neil at tigera.io>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][calico][tempest][gate] Help
	setting up DSVM gate job for networking-calico
Message-ID:
	<CAMGh4hMMnCdQ1Do8x-ohWtzJymekMkvA3UN=CMsziP0QXhJgYQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks very much, Kevin.  After removing that line that disables tempest,
things are looking a lot saner [1].  There are still other detailed things
wrong with the config, and failures to look at, but I think I know how to
attack those now.

(I also realized, from your help, that networking-calico/devstack/settings
is incorrectly confusing two things: (a) What is a minimal complete
devstack configuration, to demonstrate networking-calico function? and (b)
What are the changes to devstack configuration that should be made if
someone decides to do 'enable_plugin networking-calico'?  So I'll also see
about de-confusing that.)

      Neil

[1]
http://logs.openstack.org/63/339263/6/experimental/gate-tempest-dsvm-networking-calico-nv/3639cd8/console.html


On Fri, Oct 21, 2016 at 8:06 AM Kevin Benton <kevin at benton.pub> wrote:

> Left a comment on your patch. Looks like you have tempest disabled in your
> devstack settings file.
>
> On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram <neil at tigera.io> wrote:
>
> I'm trying to set up a dsvm gate job for networking-calico [1] - which I
> think means
> - using DevStack to set up a single combined controller/compute node, with
> networking-calico settings and plugin [2]
> - using Tempest to run some tests on that; ideally including some
> networking-related tests :-)
>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because
> of something to do with credentials, and that also seem unrelated to
> networking, and I'm not sure if any networking-related tests are running.
>
> I've tried comparing against the similar job for networking-ovn [5][6].
> Before the point where Tempest starts reporting success/failure of
> individual tests, the only notable difference I see is that the
> networking-calico output has:
>
> sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
> directory
> Running tempest with a custom regex filter
> all create: /opt/stack/new/tempest/.tox/tempest
> all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
> all develop-inst: /opt/stack/new/tempest
>
> where the networking-ovn output only has:
>
> Running tempest with a custom regex filter
> all develop-inst-noop: /opt/stack/new/tempest
>
> Is that significant?
>
> Then the next, very obvious, difference is that the networking-calico
> output seems to have the results of individual tests all jumbled up - like
> output from multiple threads without a lock:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpGuFAar
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> {0} setUpClass
> (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery) ...
> SKIPPED: TestApiDiscovery skipped as Ironic is not available
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class
> 'tempest.lib.exceptions.InvalidCredentials'> raised in
> AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
> {3} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {2} setUpClass
> (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative) ...
> SKIPPED: TestPortsNegative skipped as Ironic is not available
> 20{3} setUpClass
> (tempest.api.baremetal.admin.test_nodestates.TestNodeStates) ... SKIPPED:
> TestNodeStates skipped as Ironic is not available
> 16{0} setUpClass
> (tempest.api.compute.admin.test_agents.AgentsAdminTestJSON) [0.000000s] ...
> FAILED
> 2{3} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
> (tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
> TestChassis skipped as Ironic is not available
> 23:3020.41356 7-9 0931300006 INFO tempest.test [-] <class
> 'tempest.lib.exceptions.InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22
> t. [i3-8aIN]l6 FOs  t'30em90<p>4 IN class resFa't.O teitesmpstt
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
> 'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn
> Agitgeber.aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv
>
> whereas the networking-ovn output looks neat:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> {0} setUpClass
> (tempest.api.baremetal.admin.test_nodestates.TestNodeStates) ... SKIPPED:
> TestNodeStates skipped as Ironic is not available
> {2} setUpClass
> (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery) ...
> SKIPPED: TestApiDiscovery skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> {3} setUpClass (tempest.api.baremetal.admin.test_chassis.TestChassis) ...
> SKIPPED: TestChassis skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {1} setUpClass
> (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative) ...
> SKIPPED: TestPortsNegative skipped as Ironic is not available
> {1} setUpClass
> (tempest.api.compute.admin.test_baremetal_nodes.BaremetalNodesAdminTestJSON)
> ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_using_string_ram
> [0.232261s] ... ok
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_verify_entry_in_list_details
> [0.101537s] ... ok
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_int_id
> [0.081664s] ... ok
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_none_id
> [0.079674s] ... ok
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_flavor_with_uuid_id
> [0.075899s] ... ok
> {1}
> tempest.api.compute.admin.test_flavors.FlavorsAdminTestJSON.test_create_list_flavor_without_extra_data
> [0.409597s] ... ok
>
> I would appreciate any help as regards what I'm doing wrong here.
>
> Thanks,
>      Neil
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-calico.yaml
> [2]
> http://git.openstack.org/cgit/openstack/networking-calico/tree/devstack
> [3] https://review.openstack.org/#/c/339263/
> [4]
> http://logs.openstack.org/63/339263/5/experimental/gate-tempest-dsvm-networking-calico-nv/8d47b1c/console.html
> [5]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-ovn.yaml
> [6]
> http://logs.openstack.org/16/386016/1/check/gate-tempest-dsvm-networking-ovn/4e3924f/console.html.gz
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0610e6ce/attachment-0001.html>

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

Message: 14
Date: Fri, 21 Oct 2016 11:01:53 +0200
From: Johannes Grassler <jgrassler at suse.de>
To: OpenStack Development Mailing List
	<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Keystone][Design Session] Where to propose
	extensions to trusts?
Message-ID: <41b5666f-3c09-eb8d-537e-5d56fafaefeb at suse.de>
Content-Type: text/plain; charset=utf-8; format=flowed

Hello,

I've got a last minute proposal, or rather two of them for the Keystone side of
the design sessions in Barcelona. I guess it's something that would fit the
Authorization work session on Friday (09:00-09:40) but I'm not sure I can
simply add it on the Etherpad. Also, I may not able to attend the session in
person since I'll need to join the Barbican session in the same time slot as
well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:

1. Scope extensions for trusts
==============================

Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to
grant their service users or dedicated trustee users limited rights for various
purposes, such as deferred operations on behalf of the user or providing access to
certificate containers. These trusts can only be limited to a set of roles in a
given project right now. The Admin guide mentions an endpoint limitation on top of
that, but I haven't found any code in Keystone for handling that. I played with it
a bit and found that every keyword argument Keystone doesn't know what to do
with ends up in the trust table's `extra` column, but there's no code for doing
anything with it as far as I can tell. It would be a useful thing, though and
implementing it goes hand in hand with my proposal: I'd like to see an ability
to scope trusts to:

   1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL and nothing else")
   2) A fixed path (i.e. "This trust may only access /v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
   3) A fixed URL (i.e. "This trust may only access
      http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)

The main thing I'm currently interested in is whether this is feasible. If so,
I'd be happy to work on a blueprint and implementation. I believe this is
really important to allow services and users to limit trusts to exactly the
access level needed and not a bit more.


2. Lightweight trusts
=====================

When Keystone trusts are created the current practice is to either

   1) Delegate the trust to a service user using the trust (example: Heat)
   2) Create a dedicated trustee user for delegating the trust to (example:
      Magnum)

(1) is fine as far as I'm concerned, but I think (2) could do with some
improvement. The dedicated trustee user will have a user name and password that
needs to be used to authenticate as that user (along with a trust ID to consume
the trust). I'd rather see a long-lived trust token scoped to the trust that
can be extended upon expiry for that purpose. Just like a regular token, in
other words. For the following reasons:

   1) Everybody who creates such a user will have different idea of a secure
      password length. A token is generated by keystone in a centralized manner
      and always of a sufficient length to make for a secure secret.
   2) It requires third party software that may need to authenticate as the
      trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver
      (used by Magnum). Most such software should be able to handle an auth
      token, on the other hand.
   3) There is less cleanup required after the trust has served its purpose:
      only the trust needs to be deleted at that point, but no trustee user.

Comments on these two proposals (and advice on a suitable forum for discussing
them at the summit) would be greatly appreciated. Thank you!

Cheers,

Johannes


Footnotes:

[0] In a pinch I could probably ask a colleague to stand in for me, but I'd
     prefer a solution where I can be present for both discussions.

-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG N?rnberg)
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 N?rnberg, Germany



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

Message: 15
Date: Fri, 21 Oct 2016 17:08:57 +0800
From: hu.zhijiang at zte.com.cn
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [daisycloud-core] Meeting minutes for IRC
	meeting 0800UTC Oct. 21 2016
Message-ID:
	<OFDF353D09.BB96A698-ON48258053.00321B98-48258053.00323315 at zte.com.cn>
Content-Type: text/plain; charset="US-ASCII"

Minutes:        
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.html 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.txt 

Log:            
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.log.html 



B.R.,
Zhijiang




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

Message: 16
Date: Fri, 21 Oct 2016 09:19:40 +0000
From: Julia Aranovich <jkirnosova at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-dev][Fuel][Plugin]
Message-ID:
	<CAMfgBLVa61Gz4Rtzu+F4PVOWby1gQdAgqmSFpJmPpGpvRqB61A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Nidhi,

This implemented https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
blueprint provided an ability to use "text_list" and "textarea_list" UI
control types.
They are suitable for settings where the value is a list of strings.
These controls represent on UI a list of single or multiline text inputs
with +/- buttons to add/remove an additional element:

My Setting      value1 +/-
                       value2 +/-
                       value3 +/-
(the result value for the setting "My Setting" is ['value1', 'value2',
'value3']).


If I understand your case properly, you need something like dynamic groups
of inputs of different type.
This is still not supported by Fuel UI. The implementation does not look
simple, it requires changing of data structure in settings yaml, adding a
new level of nesting. There is a need to think thoroughly about the
details: how to organize such a setting yaml structure, how to declare a
set of inputs in such a group, how inputs should be aligned in the group
(horizontally/vertically), etc.

For now, I would suggest the following ways of how to organize your plugin
settings:

1) use text_list/textarea_list controls for each field from a group that
represents storage backend configuration:

Field1  value_for_backend_1 +/-
            value_for_backend_2 +/-
            value_for_backend_3 +/-

Field2  value_for_backend_1 +/-
            value_for_backend_2 +/-
            value_for_backend_3 +/-

Field3  value_for_backend_1 +/-
            value_for_backend_2 +/-
            value_for_backend_3 +/-

2) use text_list/textarea_list controls to configure a list of storage
backends by declaring their settings as a single comma-separated string:

Backends Settings    comma_separated_settings_for_backend_1 +/-
                    comma_separated_settings_for_backend_2 +/-
                                  comma_separated_settings_for_backend_3 +/-

>From my point of view, the first version looks more clear. Will it
suit your case, Nidhi?


Best regards,
Julia

On Fri, Oct 21, 2016 at 8:17 AM <nidhi.hada at wipro.com> wrote:

> Hi All,
>
>
> This is regarding an info required for fuel plugin development.
>
> We are working on Fuel Cinder Plugin where we require to
>
> configure multiple 'n' number of backends of storage vendor ,
>
> in one go, from Fuel UI screen. where 'n' will be known at run time.
>
>
> Its like from UI, I can configure a set of fields, [field1, field2,
> field3]
>
> for one backend and if user ask to configure 'n' backends then same
>
> set of fields to be asked repeatedly.
>
>
> I have found some similar provision was planned in
>
> https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
>
>
> But when i see implementation
> https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z
>
> which implements new type as text_list and textarea_list ..
>
> which is capability to add multiple lines of text in single field..
>
>
> It does not look like same as aim of BP, where acceptance criteria for BP
> is
>
> "Enable text and textarea field types to be extended - where a plugin user
> is able to toggle the visibility of additional fields with +/- signs and
> the data provided is used by plugin"
>
>
> Kindly correct my understanding if its wrong, do we have capability to add
> a text field by pressing +/- ?
>
> What capability do we have with Fuel UI to add fields dynamically today ?
>
>
> I have read
> https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel
>
> [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI -
> OpenStack Mailing List Archive
> <https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel>
> openstack.nimeyo.com
> Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp
> (to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> where suggestions are made to use restrictions to hide display components.
>
>
> Another suggestion is to use comma separated values.
>
>
> But its an year back post, do we have a better solution today ?
>
>
> Will be helpful if someone can suggest how do we achieve it in fuel UI.
>
>
>
> Thanks
>
> Nidhi
>
>
>
>
>
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/1848bace/attachment-0001.html>

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

Message: 17
Date: Fri, 21 Oct 2016 20:23:12 +1100
From: Gilles Dubreuil <gdubreui at redhat.com>
To: OpenStack-dev at lists.openstack.org
Subject: [openstack-dev] [all] Automation and self described APIs
Message-ID: <3ce11c50-24da-9e30-9017-92c20c57f213 at redhat.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Ok, OpenStack ransom of success means the APIs request list is growing.
So what's the plan for self-described APIs?
Do we have a standardized solution exposing the requests' methods, 
parameters to other program to exploit?

Sure, some OpenStack APIs advertise their interface using GET method 
such as {"show api version", "/v1/"}.
Although consistent in the format but not available across all projects, 
it doesn't seem to be following a standard anyway, right?
Besides and more importantly it isn't suitable to fully expose the 
requests interfaces.

We know REST is not a standard in itself, but RESTful implementations 
make use of standards, such as HTTP, URI, JSON and XML [1]
This have brought an excellent candidate tailored for the job, the HTTP 
OPTION, please see RFC2616 [2] for more details.
Using such an approach would allow OpenStack APIs requests interfaces 
(methods, parameters and items) to be advertised to other programs.
By offering a new level of API automation, almost over are the days of 
tedious work for every OpenStack client of creating or adding every 
interface corresponding code and its test code.
The next generation of RESTful clients could get up to date automatically.

In the meantime that happens, the only comprehensive APIs reference 
source I've found is developer.openstack.org/api-ref.html 
<http://developer.openstack.org/api-ref.html> [2].
BTW, great work Oslo Sphinx team, thank you!
The API-ref allows most of APIs interfaces to be partly generated using 
web crawlers.
Unfortunately, there a still missing projects from the reference so the 
rest still has to be manually produced and for the one automatically 
generated there are various flaws which require manual intervention.

The flaws I've found:
- Missing requests from API ref: Only a few (example? Ironic: heartbeat  
POST, "/v1/heartbeat/{node_ident}")
- API Inconsistencies: For instance, the call a method for Node Vendor 
[3] or Driver Vendor [4] Passthru is the same, which create a conflict 
for REST Clients.

So again, the API-ref is great and allow to cover the requests list but 
that's not good enough for automation where the requests capabilities 
need to be advertised properly and comprehensively through a standard, 
such as the HTTP Option. Actually the API-ref could benefit from it too 
and consume the latter.

Cheers,
Gilles

PS: In an ideal world, the API is built first and the rest upon.

[1] https://en.wikipedia.org/wiki/Representational_state_transfer
[2] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[3] 
http://developer.openstack.org/api-ref/baremetal/?expanded=call-a-method-detail
[4] http://developer.openstack.org/api-ref/baremetal/?expanded=id73-detail

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

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

Message: 18
Date: Fri, 21 Oct 2016 12:06:46 +0100 (BST)
From: Chris Dent <cdent+os at anticdent.org>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Does it make sense to have self links to
	things that don't exist?
Message-ID: <alpine.OSX.2.20.1610211205410.52839 at shine.local>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Thu, 20 Oct 2016, Matt Riedemann wrote:

> It's not convenient, IMO, to provide a link to something that doesn't exist. 
> That's just frustrating from the API user point of view.
>
> So is this fine?
> Should it be implemented?
> Or should the docs say, the link might not exist?
> Or should the link to the non-existent handler just be removed?

If the discovery doc is for discovering stuff, it shouldn't list stuff
that doesn't exist. That's pretty simple and straightforward, right?
How could it be anything else?

-- 
Chris Dent               ????( ? _ ??)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent

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

Message: 19
Date: Fri, 21 Oct 2016 12:07:08 +0100
From: Lee Yarwood <lyarwood at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [nova][cinder] Addressing mangled LUKS
	passphrases	(bug#1633518)
Message-ID:
	<20161021110708.sqql3h3sddaezld7 at lyarwood.usersys.redhat.com>
Content-Type: text/plain; charset=utf-8

Hello,

I documented bug#1633518 [1] last week in which volumes encrypted prior
to Ib563b0ea [2] used a slightly mangled passphrase instead of the
original passphrase provided by the configured key manager.

My first attempt at resolving this [3] prompted an alternative
suggestion from mdbooth of adding the correct passphrase to the LUKS
device when we detect the use of a mangled passphrase.

I'm slightly wary of this option given the changing of passphrases so
I'd really appreciate input from the wider Nova and Cinder groups on
your preference for resolving this :

1. Keep the mangled passphrase in place and attempt to use it after
getting a permission denied error during luksOpen. 

2. Add the correct passphrase and remove the mangled passphrase from the
LUKS device with luksChangeKey when we detect the use of the mangled
passphrase.

3. An alternative suggestion.

FYI, as os-brick has now copied the encryptor classes from Nova into
their own tree any fix will be cherry-picked across shortly after
landing in Nova. I'm also looking into dropping these classes from Nova
for Ocata so we can avoid duplicating effort like this in future.

Thanks in advance,

Lee

[1] https://launchpad.net/bugs/1633518
[2] https://review.openstack.org/#/c/309614/
[3] https://review.openstack.org/#/c/386670/
-- 
Lee Yarwood
Senior Software Engineer
Red Hat

PGP : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76



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

Message: 20
Date: Fri, 21 Oct 2016 12:22:52 +0100 (BST)
From: Chris Dent <cdent+os at anticdent.org>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID: <alpine.OSX.2.20.1610211213490.52839 at shine.local>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Wed, 19 Oct 2016, Sean Dague wrote:

> The reason we have volume, volumev2, and volumev3 is that no one actually 
> wants the unversioned volume endpoint. You can't do anything with it. 
> Everyone wants the actual endpoint that has resources.

That's right, they do want the endpoint that has the resources, but
do they care about asking for a version? I'm not sure. I think they
just want the thing that's going to work and the version is
superfluous.

> We can solve this for all consumers by adding additional version field to the 
> catalog. This was the direction we were headed last spring before the api-ref 
> work took over.

I'd rather not see versions in the service catalog as a reified entity
because it increases the surface area of an endpoint request. I don't
want to have think which version I want. Or if I do, I want it to be
built into the service type. We want the service type to be the
entrypoint for endpoints...

In any case, just for reference, both the arch-wg and the api-wg
have expressed a lot of concern about and interest in the service
catalog (and the service authority idea that was bouncing around for
a while too). So I agree with everyone else who is saying "yeah,
it's time to make this better."

There are a lot of issues:

* how to deal with versions
* auth handling at the top-level endpoint
* service type value consistency amongst clouds
* public, internal, admin, whatever endpoints (can we make it so
   there is one and only one?)
* dynamic v static service catalogs in the face of different
   contexts
* whatever else I'm forgetting right now because the coffee is weak
   but I'm sure someone else remembers

-- 
Chris Dent               ????( ? _ ??)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent

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

Message: 21
Date: Fri, 21 Oct 2016 12:41:16 +0100 (BST)
From: Chris Dent <cdent+os at anticdent.org>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [all] indoor climbing break at summit?
Message-ID: <alpine.OSX.2.20.1610211239040.52839 at shine.local>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Tue, 18 Oct 2016, Miles Gould wrote:

> Speaking of which: woo yeah! I'm totally up for this, schedule permitting.

The etherpad is gathering steam, on Monday I'll use the email
addresses on there and send out a plan, so anyone who wants to be
notified, look there, or just show up at the gym at the chosen time.

https://etherpad.openstack.org/p/ocata-climb

-- 
Chris Dent               ????( ? _ ??)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent

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

Message: 22
Date: Fri, 21 Oct 2016 07:41:52 -0400
From: Doug Hellmann <doug at doughellmann.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all
Message-ID: <99262145-B20A-4A8A-8AFF-465BF2E8E7B2 at doughellmann.com>
Content-Type: text/plain;	charset=utf-8



> On Oct 21, 2016, at 7:22 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
>> On Wed, 19 Oct 2016, Sean Dague wrote:
>> 
>> The reason we have volume, volumev2, and volumev3 is that no one actually wants the unversioned volume endpoint. You can't do anything with it. Everyone wants the actual endpoint that has resources.
> 
> That's right, they do want the endpoint that has the resources, but
> do they care about asking for a version? I'm not sure. I think they
> just want the thing that's going to work and the version is
> superfluous.
> 
>> We can solve this for all consumers by adding additional version field to the catalog. This was the direction we were headed last spring before the api-ref work took over.
> 
> I'd rather not see versions in the service catalog as a reified entity
> because it increases the surface area of an endpoint request. I don't
> want to have think which version I want. Or if I do, I want it to be
> built into the service type. We want the service type to be the
> entrypoint for endpoints...
> 
> In any case, just for reference, both the arch-wg and the api-wg
> have expressed a lot of concern about and interest in the service
> catalog (and the service authority idea that was bouncing around for
> a while too). So I agree with everyone else who is saying "yeah,
> it's time to make this better."

This is the sort of issue that would work well as a community-wide goal. If we get a group together to resolve some of the issues you list below, they can act as guides to steer the work and help teams with the transition. If we act quickly maybe we can make enough progress to do it for Pike. 

Doug

> 
> There are a lot of issues:
> 
> * how to deal with versions
> * auth handling at the top-level endpoint
> * service type value consistency amongst clouds
> * public, internal, admin, whatever endpoints (can we make it so
>  there is one and only one?)
> * dynamic v static service catalogs in the face of different
>  contexts
> * whatever else I'm forgetting right now because the coffee is weak
>  but I'm sure someone else remembers
> 
> -- 
> Chris Dent               ????( ? _ ??)        https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Message: 23
Date: Fri, 21 Oct 2016 12:44:21 +0100 (BST)
From: Chris Dent <cdent+os at anticdent.org>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query
Message-ID: <alpine.OSX.2.20.1610211242140.52839 at shine.local>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Fri, 21 Oct 2016, Alex Xu wrote:

> Also think 404 is right at here. If you return 406 and it is a signal that
> if you used a different microversion the situation could be different, the
> thing will become strange when we raise the acceptable min_version someday.

Thanks, yeah, what you and Ed have said has been convincing, I've
updated the code at: https://review.openstack.org/#/c/388115/

Jay's review of that has raised a new issue: which is should we even
bother with the decorator style?


-- 
Chris Dent               ????( ? _ ??)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent

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

_______________________________________________
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 54, Issue 52
*********************************************



More information about the OpenStack-dev mailing list