Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Tom Cameron]

Hi all,

I just wanted to make a note about a couple things here. I'll also try to 
attend any meeting that is scheduled.

GLSB may be implemented a few ways.​ ​One method is via DNS, as Kunal 
mentioned. It's not very granular and unless you have very low TTL on your 
records and the ability to change your records rapidly at the edge, it can be 
difficult to control.

​A second way to implement ​GSLB is to use Layer 7 to redirect client traffic. 
Typically you'll tell a load balancer where to redirect traffic and it will do 
something like an HTTP redirect. I've used this implementation for things like 
site maintenance, or load based redirection. (I think A10 and F5 implement 
Layer 7 GSLB solutions in at least some of their products that offer GSLB?)

Something to keep in mind about a DNS based strategy is that recursive 
resolvers may not respect record order, some implement broken caching (ignoring 
authoritative TTL values), and that authoritative servers may not be queried 
evenly.
  
I'd be very happy to discuss specifics offline with anybody that might have 
questions about authoritative DNS operator quirks, implementations, or what 
they generally see behavior wise from recursive servers. Otherwise, I look 
forward to the meeting.

-- 
Tom Cameron  
Network Architect
Rackspace




From: Gandhi, Kunal 
Sent: Friday, May 22, 2015 22:24
To: openstack-dev@lists.openstack.org
Cc: do...@a10networks.com; v.jain...@gmail.com
Subject: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support
  
Hi All


I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
and designate. To be brief for folks who are new to GLB, GLB stands for Global 
Load Balancing and we use it for load balancing traffic across various 
geographical regions.  A more detail description of GLB can be found at my talk 
at the summit this week here.


To my understanding, there are two sides to a GSLB - DNS side and LB side. 


DNS side
Most of the GSLB’s provided by various vendors are DNS servers and are 
authoritative for the GLB domains. The global fqdn’s that belong the GLB 
domains resolve to multiple public VIP’s  across various regions based on 
various configurations on the global fqdn on the GLB.


LBaaS side
A few of the common functionalities provided by a standard GSLB provides are 
health monitoring on the public VIP’s and the local LB’s on which these public 
VIP’s sit on. Some additional  features that a GSLB can provide are configuring 
admin status and weights on your public VIP’s. Based on these configurations 
and settings, the GLB returns the appropriate number of public VIP’s to any DNS 
resolve queries for the global fqdn’s.

I would like to have the designate and lbaas to start a discussion on GSLB and 
discuss the following topics:

What parts of GSLB belongs to Designate and LBaaS ?
Once we have an understanding of the above, my team at eBay/PayPal would like 
work with the community on submitting a blueprint for this.

To kick start this conversation, I would like to schedule an irc meeting 
regarding this with folks from designate and neutron-lbaas. Please let me know 
a time and day that works for you guys. I am available on Thursday and Friday 
next week.


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

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Doug Wiegley]

Of those two options, Friday would work better for me.

Thanks,
doug

> On May 22, 2015, at 9:33 PM, ki...@macinnes.ie wrote:
> 
> Hi Kunal,
> 
> Thursday/Friday works for me - early morning PT works best, as I'm based in 
> Ireland.
> 
> I'll find some specific times the Designate folks are available over the next 
> day or two and provide some options..
> 
> Thanks,
> Kiall
> 
> On 22 May 2015 7:24 pm, "Gandhi, Kunal"  wrote:
> Hi All
> 
> I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
> and designate. To be brief for folks who are new to GLB, GLB stands for 
> Global Load Balancing and we use it for load balancing traffic across various 
> geographical regions. A more detail description of GLB can be found at my 
> talk at the summit this week here 
> .
> 
> To my understanding, there are two sides to a GSLB - DNS side and LB side. 
> 
> DNS side
>   Most of the GSLB’s provided by various vendors are DNS servers and are 
> authoritative for the GLB domains. The global fqdn’s that belong the GLB 
> domains resolve to multiple public VIP’s across various regions based on 
> various configurations on the global fqdn on the GLB.
> 
> LBaaS side
>   A few of the common functionalities provided by a standard GSLB 
> provides are health monitoring on the public VIP’s and the local LB’s on 
> which these public VIP’s sit on. Some additional features that a GSLB can 
> provide are configuring admin status and weights on your public VIP’s. Based 
> on these configurations and settings, the GLB returns the appropriate number 
> of public VIP’s to any DNS resolve queries for the global fqdn’s.
> 
> I would like to have the designate and lbaas to start a discussion on GSLB 
> and discuss the following topics:
> 
> What parts of GSLB belongs to Designate and LBaaS ?
> Once we have an understanding of the above, my team at eBay/PayPal would like 
> work with the community on submitting a blueprint for this.
> 
> 
> To kick start this conversation, I would like to schedule an irc meeting 
> regarding this with folks from designate and neutron-lbaas. Please let me 
> know a time and day that works for you guys. I am available on Thursday and 
> Friday next week.
> 
> 
> Regards
> Kunal
> 
>   
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Zane Bitter]

On 22/05/15 19:01, Fox, Kevin M wrote:

I believe that trove still needs the multi tenant isolation of a multi
tenant message queue due to the fact that the vm runs in the tenant, and
the tenant can then force a reboot, go to the console, root it, and
inject messages at queues destened for other tenants vm's. And there are
other routes too.


So what I gathered is that according to the Trove folks you are Doing It 
Wrong(TM), even though you installed it in the default configuration. 
You should have modified the Trove code in undocumented ways to create 
the VMs in a project that Trove itself owns, not the user's project.



This is a major problem, and I think our site is going to have to
strongly consider uninstalling trove until fixed.


I think if you made that change the configuration it would be a lot less 
dangerous. Arguably even then it would be better to use something 
multi-tenant capable and authenticated (if it's so safe why not use the 
same RabbitMQ as all the other services?), but it would be less of an 
'immediate uninstall' case.


cheers,
Zane.


Thanks,
Kevin *
*

*From:* Zane Bitter
*Sent:* Friday, May 22, 2015 12:34:01 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my
notes

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.


I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.


I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.


I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.


I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).


Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.


I gather there is currently no oslo.messaging integration with zaqar;


Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)


for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.


Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.


It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a ni

Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[kiall]

Hi Kunal,
Thursday/Friday works for me - early morning PT works best, as I'm based in Ireland.
I'll find some specific times the Designate folks are available over the next day or two and provide some options.. 
Thanks,
Kiall
On 22 May 2015 7:24 pm, "Gandhi, Kunal"  wrote:Hi AllI wanted to start a discussion about adding support for GSLB to neutron-lbaas and designate. To be brief for folks who are new to GLB, GLB stands for Global Load Balancing and we use it for load balancing traffic across various geographical regions. A more detail description of GLB can be found at my talk at the summit this week here.To my understanding, there are two sides to a GSLB - DNS side and LB side. DNS side	Most of the GSLB’s provided by various vendors are DNS servers and are authoritative for the GLB domains. The global fqdn’s that belong the GLB domains resolve to multiple public VIP’s across various regions based on various configurations on the global fqdn on the GLB.LBaaS side	A few of the common functionalities provided by a standard GSLB provides are health monitoring on the public VIP’s and the local LB’s on which these public VIP’s sit on. Some additional features that a GSLB can provide are configuring admin status and weights on your public VIP’s. Based on these configurations and settings, the GLB returns the appropriate number of public VIP’s to any DNS resolve queries for the global fqdn’s.I would like to have the designate and lbaas to start a discussion on GSLB and discuss the following topics:What parts of GSLB belongs to Designate and LBaaS ?Once we have an understanding of the above, my team at eBay/PayPal would like work with the community on submitting a blueprint for this.To kick start this conversation, I would like to schedule an irc meeting regarding this with folks from designate and neutron-lbaas. Please let me know a time and day that works for you guys. I am available on Thursday and Friday next week.RegardsKunal	
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][app-catalog] App Catalog next steps

[Christopher Aedo]

I want to start off by thanking everyone who joined us at the first
working session in Vancouver, and those folks who have already started
adding content to the app catalog. I was happy to see the enthusiasm
and excitement, and am looking forward to working with all of you to
build this into something that has a major impact on OpenStack
adoption by making it easier for our end users to find and share the
assets that run on our clouds.

The catalog: http://apps.openstack.org
The repo: https://github.com/stackforge/apps-catalog
The wiki: https://wiki.openstack.org/wiki/App-Catalog

Please join us via IRC at #openstack-app-catalog on freenode.

Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox,
Serg Melikyan.

I’ve started a doodle poll to vote on the initial IRC meeting
schedule, if you’re interested in helping improve and build up this
catalog please vote for the day/time that works best and get involved!
http://doodle.com/vf3husyn4bdkui8w

At the summit we managed to get one planning session together. We
captured that on etherpad[1], but I’d like to highlight here a few of
the things we talked about working on together in the near term:

-More information around asset dependencies (like clarifying
requirements for Heat templates or Glance images for instance),
potentially just by providing better guidance in what should be in the
description and attributes sections.
-With respect to the assets that are listed in the catalog, there’s a
need to account for tagging, rating/scoring, and a way to have
comments or a forum for each asset so potential users can interact
outside of the gerrit review system.
-Supporting more resource types (Sahara, Trove, Tosca, others)
-Discuss using glance artifact repository as the backend rather than
flat YAML files
-REST API, enable searching/sorting, this would ease native
integration with other projects
-Federated catalog support (top level catalog including contents from
sub-catalogs)
- I’ll be working with the OpenStack infra team to get the server and
CI set up in their environment (though that work will not impact the
catalog as it stands today).

There were a ton of great ideas that came up and it was clear there
was WAY more to discuss than we could accomplish in one short session
at the summit.  I’m looking forward to continuing the conversation
here on the mailing list, on IRC, and in Tokyo as well!

[1] https://etherpad.openstack.org/p/YVR-app-catalog-plans

-Christopher

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

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Sheng Bo Hou]

I am not a core, but I support with +1 from my heart.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193



Jay Bryant  
05/23/2015 11:22 AM
Please respond to
jsbry...@electronicjungle.net; Please respond to
"OpenStack Development Mailing List \(not for usage questions\)" 



To
"OpenStack Development Mailing List (not for usage questions)" 

cc

Subject
Re: [openstack-dev] [cinder] Some Changes to Cinder Core






+1 Well deserved.  Welcome to Core Sean! It is a pleasure to work with 
you! 
Thanks to Avishay for all his contributions!  Sorry to see you go. 
Jay
On May 22, 2015 4:36 PM, "Mike Perez"  wrote:
This is long overdue, but it gives me great pleasure to nominate Sean
McGinnis for
Cinder core.

Reviews:
https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z

Contributions:
https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z

30/90 day review stats:
http://stackalytics.com/report/contribution/cinder-group/30
http://stackalytics.com/report/contribution/cinder-group/90

As new contributors step up to help in the project, some move onto
other things. I would like to recognize Avishay Traeger for his
contributions, and now
unfortunately departure from the Cinder core team.

Cinder core, please reply with a +1 for approval. This will be left
open until May 29th. Assuming there are no objections, this will go
forward after voting is closed.

--
Mike Perez

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


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

[openstack-dev] [cinder] Thanks to all the folks on the plane tour to glaciers

[Sheng Bo Hou]

Hi all the folks on the plane tour to the glaciers,

This is Vincent Hou. I am sorry about getting a bit plane-sick during our 
trip. It was a sort of harsh for me, but the wonderful thing is that
I really enjoyed the snow, the mountain, the lake, the glaciers, etc. I 
hope the uncomfortable me did not bring too much trouble to you folks.
It felt like that the blood in my body had stopped flowing. I got no 
strength to see, no strength to hear, no strength to sit, even no strength
to think... Sorry about that I did not even say goodbye and wish you folks 
a nice trip back to your place.

Thank Kurt. This trip is perhaps the only once in my life with the best 
view I ever see.
Thank Sean. You words helped me a lot. I might not be able to make the 
trip in the last section without them.
Thank Jay, Walter... Thank everybody.

One more request in the end. Can you guys share some photos you have taken 
in our tour? I have missed some view. Thank you so much.

I am feeling much better now in the hotel. Take care, folks! Safe trip 
back home! See you.


Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Jay Bryant]

+1 Well deserved.  Welcome to Core Sean! It is a pleasure to work with you!

Thanks to Avishay for all his contributions!  Sorry to see you go.

Jay
On May 22, 2015 4:36 PM, "Mike Perez"  wrote:

> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
>
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>
> Contributions:
> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
>
> 30/90 day review stats:
> http://stackalytics.com/report/contribution/cinder-group/30
> http://stackalytics.com/report/contribution/cinder-group/90
>
> As new contributors step up to help in the project, some move onto
> other things. I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
>
> Cinder core, please reply with a +1 for approval. This will be left
> open until May 29th. Assuming there are no objections, this will go
> forward after voting is closed.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

[Debojyoti Dutta]

Sorry Steven, Sergey, saw the email late. If there is an informal meetup
tonight, please let me know :)

Else see you on IRC

debo

On Fri, May 22, 2015 at 9:54 AM, Steven Dake (stdake) 
wrote:

>  Debo,
>
>  The Sahara cats are having a contributors meetup right now in room 218.
> @ ODS.  I have prior commitments so won’t be able to attend, but perhaps
> some of the cognitive folks could make the meetup there.
>
>  Sergey,
>
>  If the Sahara contributors plan on walking the city tonight, feel free
> to send me info off-list and I’ll try to make it.
>
>  Regards
> -steve
>
>
>   From: Sergey Lukjanov 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, May 22, 2015 at 9:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a
> project to deliver Machine Learning as a Service for OpenStack
>
>   So, in case if Cognitive will use Sahara to create big data clusters -
> then it sounds ok.
>
> On Fri, May 22, 2015 at 8:54 AM, Debojyoti Dutta  wrote:
>
>> One more thing and a typo in my mail  -  we would be happy to point folks
>> to an very early version (in Django) we prototyped and opened up recently.
>>
>>  thx
>> debo
>>
>>
>>
>> On Fri, May 22, 2015 at 8:48 AM, Debojyoti Dutta 
>> wrote:
>>
>>> Hi Sergey
>>>
>>>  Thanks a lot for your interest. The bare bones API proposal is up on
>>> the wiki page http://wiki.openstack.org/Cognitive
>>>
>>>  Sahara is about deploying and managing big data workloads like hadoop,
>>> spark etc. Cognitive is about a simple API to do predictive analytics,
>>> learning, data science workflow etc etc. Thus the goals are different. AWS
>>> has Elastic MapReduce (in the same space as Sahara) and also AWS Machine
>>> Learning (http://aws.amazon.com/machine-learning/) for which there is
>>> no parallel. Should we point them to our internal 1st version of Cognitive
>>> on our github which we opened.
>>>
>>>  If it requires to use big data toolchains to do our job, we will
>>> definitely leverage Sahara for that, and not replicate the good work done
>>> in Sahara. Our primary goal is to build (within the community) a simple
>>> machine learning API (and a service) that abstracts the pain of data
>>> science for the app developer.
>>>
>>>
>>>  thx
>>>
>>> debo
>>>
>>>
>>>  PS: FWIW  I am at the summit till tonight so we could catch up here.
>>>
>>>
>>>
>>> On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov >> > wrote:
>>>
 Hi,

  as there is no any details on the project yet done, if this project
 will deploy ML frameworks it'll be direct duplication of Sahara's
 functionality (we already support HDP and CDH deployments and they are
 provided tons of tools for ML). So, I think that it could be built on top
 of Sahara or even as part of Sahara probably. I'd like to propose you to
 take a deeper look on Sahara and avoid duplicating it.

  Thanks.

 On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta 
 wrote:

> Hi Salvatore
>
>  Thanks a lot for your comments.
>
>  Timing: Yes it is time to do this! The nature of applications
> running on clouds is indeed changing.
>
>  Initial group: We asked around for folks interested and we got a lot
> more people than we expected. The idea is to get something out there in a
> stack forge project and build something good. This group already has 
> people
> who have built things like this already in the past. Hence confident about
> the success.
>
>  Participation: We want this to be inclusive from scratch independent
> of who is a PTL or a contributor or merely a curious individual to give us
> ideas :) The community will get it right. Maybe I should have clarified
> that these are the members interested in seeing this happen.
>
>  Wiki page: The wiki page will be ready in 1-2 days. Also we would
> like to have a discussion during the summit to see what we should build in
> the community. Would be delighted to get your thoughts.
>
>  Services: Some of the services this could provide:
> * create experiments: define data sources, train models, then perform
> classification, clustering, data cleaning etc.
> * have experiment templates that can be reused
> * have an editor (maybe a horizon plugin) to drag and drop the
> workflow and generate an API that when called from an app would provide
> results
> * ML primitives that could be targeted initially: 1) classification
>  2) clustering 3) Anomaly detection
>
>  thx
> debo
>
> On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando <
> sorla...@nicira.com> wrote:
>
>>
>>  On 15 May 2015 at 00:19, Debojyoti Dutta  wrote:
>>
>>>  Hi!
>>>
>>>  It is a great pleasure to announce th

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Clay Gerrard]

FWIW, as a nod to the great people we've had the privilege of working with
as Swift Core Maintainers - we've taking to promoting people who have moved
on to Core Emeritus:

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

On Fri, May 22, 2015 at 4:34 PM, Mike Perez  wrote:

> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
>
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>
> Contributions:
> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
>
> 30/90 day review stats:
> http://stackalytics.com/report/contribution/cinder-group/30
> http://stackalytics.com/report/contribution/cinder-group/90
>
> As new contributors step up to help in the project, some move onto
> other things. I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
>
> Cinder core, please reply with a +1 for approval. This will be left
> open until May 29th. Assuming there are no objections, this will go
> forward after voting is closed.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

[Adrian Otto]

Thanks Richard. I found the following questions in the etherpad:

> How do we give an environment on OpenStack resources to someone who just 
> wants to 
> use Docker ?

In that case use Magnum, and have the user start a Docker Swarm bay. Then they 
can point their docker client directly at the swarm master using the value in 
the api_address attribute in the bay. I can make a demo of this if there is 
interest. It can be of node count 1 if you only want a single server, and that 
can be later adjusted if a larger bay is desired.

The rationale here is that the user will end up with a Docker API and a place 
to point a native docker client. When the bay fills up, it can be easily scaled 
out without reconfiguring the client, or bouncing around between different 
hosts like you would need to do if you were using something like Docker Machine 
with no Swarm. If you care about container placement, you can tag your swarm 
nodes, and use scheduling hints to cause the desired placement among available 
hosts.

> Who manages the docker instance versus who manages the cloud infra?

Magnum bays are properly multi-tenant isolated, provided that your nova service 
produces instances that are properly isolated. If you use a nova virt driver 
that produces bare metal servers or virtual machines, then it will be. With 
Magnum Docker containers can be completely managed by the cloud user, and the 
nova instances can be managed by them as well, if desired. This is important in 
order to allow a full range of capabilities, as some things involve accessing 
the host. One example is how to debug problems. The ability to log into the 
nova instance and poke around with a full range of debugging tools is very 
handy.

Regards,

Adrian

> On May 20, 2015, at 8:46 PM, Richard Raseley  wrote:
> 
> I apologize if this message is inappropriately broad, but I wanted to share 
> the results of the Vancouver Summit operations containers session[0] we held 
> yesterday with all of the projects which were mentioned.
> 
> This was a great discussion with approximately two-dozen individuals in 
> attendance. Most of the conversation was captured pretty well on the 
> etherpad, which can be found here:
> 
> https://etherpad.openstack.org/p/YVR-ops-containers
> 
> A big thank you to everyone who participated - it was really informative.
> 
> Regards,
> 
> Richard Raseley
> 
> SysOps Engineer @ Puppet Labs
> 
> [0] - http://sched.co/3B45
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [designate] and [lbaas] - GSLB API and backend support

[Gandhi, Kunal]

Hi All

I wanted to start a discussion about adding support for GSLB to neutron-lbaas 
and designate. To be brief for folks who are new to GLB, GLB stands for Global 
Load Balancing and we use it for load balancing traffic across various 
geographical regions. A more detail description of GLB can be found at my talk 
at the summit this week here .

To my understanding, there are two sides to a GSLB - DNS side and LB side. 

DNS side
Most of the GSLB’s provided by various vendors are DNS servers and are 
authoritative for the GLB domains. The global fqdn’s that belong the GLB 
domains resolve to multiple public VIP’s across various regions based on 
various configurations on the global fqdn on the GLB.

LBaaS side
A few of the common functionalities provided by a standard GSLB 
provides are health monitoring on the public VIP’s and the local LB’s on which 
these public VIP’s sit on. Some additional features that a GSLB can provide are 
configuring admin status and weights on your public VIP’s. Based on these 
configurations and settings, the GLB returns the appropriate number of public 
VIP’s to any DNS resolve queries for the global fqdn’s.

I would like to have the designate and lbaas to start a discussion on GSLB and 
discuss the following topics:

What parts of GSLB belongs to Designate and LBaaS ?
Once we have an understanding of the above, my team at eBay/PayPal would like 
work with the community on submitting a blueprint for this.


To kick start this conversation, I would like to schedule an irc meeting 
regarding this with folks from designate and neutron-lbaas. Please let me know 
a time and day that works for you guys. I am available on Thursday and Friday 
next week.


Regards
Kunal

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

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[yang, xing]

Definitely +1!

Thanks,
Xing


-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Friday, May 22, 2015 7:34 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cinder] Some Changes to Cinder Core

This is long overdue, but it gives me great pleasure to nominate Sean McGinnis 
for Cinder core.

Reviews:
https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z

Contributions:
https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z

30/90 day review stats:
http://stackalytics.com/report/contribution/cinder-group/30
http://stackalytics.com/report/contribution/cinder-group/90

As new contributors step up to help in the project, some move onto other 
things. I would like to recognize Avishay Traeger for his contributions, and 
now unfortunately departure from the Cinder core team.

Cinder core, please reply with a +1 for approval. This will be left open until 
May 29th. Assuming there are no objections, this will go forward after voting 
is closed.

--
Mike Perez

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

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

[openstack-dev] [Horizon] dashboard-app split in horizon

[Richard Jones]

As part of the ongoing Horizon project code reorganisation, we today agreed
to clean up the Horizon-the-Framework and OpenStack Dashboard separation
issue by doing a couple of things:

1. nuke (the recently-created) horizon dashboard-app by moving the angular
app over to dashboard and the other contents to appropriate places (mostly
under the heading of "tech-debt" :)
2. move base.html, _conf.html and _scripts.html from horizon over to
dashboard.

Thanks to Cindy, Sean and Thai for the pair (er triple?) programming
keeping me honest today.

The first step is done and captured in several linked patches based off
your leaf patch "ngReorg - Create dashboard-app" <
https://review.openstack.org/#/c/184597/> (yes, I am nuking the thing
created by your patch).

I've not done the second step, but might find some time since I have 6
hours to waste in LAX tomorrow.


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

Re: [openstack-dev] [Nova] Using depends-on for patches which require an approved spec

[Morgan Fainberg]

This seems like a good idea for a pattern in general to use gong forward. 


--Morgan
Sent via mobile

> On May 22, 2015, at 14:57, Michael Still  wrote:
> 
> Hey,
> 
> it would be cool if devs posting changes for nova which depend on us
> approving their spec could use Depends-On to make sure their code
> doesn't land until the spec does.
> 
> Just my random thought for the day.
> 
> Michael
> 
> -- 
> Rackspace Australia
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Huang Zhiteng]

+1

On Fri, May 22, 2015 at 4:55 PM, Duncan Thomas 
wrote:

> +1 without hesitation
> On 22 May 2015 16:36, "Mike Perez"  wrote:
>
>> This is long overdue, but it gives me great pleasure to nominate Sean
>> McGinnis for
>> Cinder core.
>>
>> Reviews:
>> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>>
>> Contributions:
>> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
>>
>> 30/90 day review stats:
>> http://stackalytics.com/report/contribution/cinder-group/30
>> http://stackalytics.com/report/contribution/cinder-group/90
>>
>> As new contributors step up to help in the project, some move onto
>> other things. I would like to recognize Avishay Traeger for his
>> contributions, and now
>> unfortunately departure from the Cinder core team.
>>
>> Cinder core, please reply with a +1 for approval. This will be left
>> open until May 29th. Assuming there are no objections, this will go
>> forward after voting is closed.
>>
>> --
>> Mike Perez
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [puppet] Distribution (in)dependent acceptance tests

[Gabriele Cerami]

Hi,

why are current beaker-rspec tests installing puppet from puppetlabs
instead of using a package from a distribution repo, like what is done
for git ?

More generally, spec_helper_acceptance.rb is setting up what it seems to
be a distribution independent environment that is using a lot of
external repos, and only in part the packages offered by the
distributions. Generic dependencies (like puppet-inifile) and even
specific dependencies (like puppet-keystone) are probably already
offered by distribution packages.

I think that doing this defeats in part the purpose of launching
acceptance tests on different distributions, because a consistent part
of the test environment remains always the same.

--
Gabriele "panda" Cerami
Software Engineer, Openstack CI
Red Hat


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

Re: [openstack-dev] [puppet] OpenStack Puppet modules boilerplate

[Emilien Macchi]

On 05/22/2015 04:53 PM, Sebastien Badia wrote:
> Hi,
> 
> During the Puppet session (during the Vancouver summit), we talked about
> a boilerplate
> OpenStack Puppet modules for the new ones. Especially about « compliant
> » and approved
> puppet modules.
> 
> We talked about puppet-modules-skeleton (using the gareth example¹) and
> tried
> using skeleton for our needs² but unfortunately puppet module and skeleton
> boilerplate doesn't fit because we can't template a directory name or
> a file name (puppet module generate use only erb).
> 
> Spredzy therefore proposed cookiecutter (this tool is also used by
> OpenStack³),
> and it works very smoothly :-)
> For a new OpenStack puppet module, just run:
> 
>  $ cookiecutter
> https://github.com/enovance/cookiecutter-openstack-puppet-modules.git
> 
> And after a bit of msync, voila!
> 
> I'll migrate enovance/cookiecutter-openstack-puppet-modules to
> stackforge. The repo name is OK for you? Or you prefer a name starting
> by puppet- something in
> order to easily catch-up all our modules?

I would vote for puppet-openstack-cookiecutter
because it's consistent with
https://github.com/openstack-dev/oslo-cookiecutter:
-cookiecutter.

Thanks for this work!

> 
> Yanis, Seb
> 
> ¹https://github.com/garethr/puppet-module-skeleton
> ²https://github.com/enovance/puppet-module-skeleton
> ³https://github.com/openstack-dev/cookiecutter
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [Puppet] puppet-openstack_zeromq module

[Emilien Macchi]

On 05/20/2015 07:08 PM, Richard Raseley wrote:
> Harish Kumar wrote:
>> Hello All,
>>
>> I have written a puppet-openstack_zeromq module using which one can
>> install/configure openstack zeromq reciever.
>>
>> I would like to know if it make sense to host that code with other
>> openstack related puppet module.
>>
>> Please see the code - https://github.com/jiocloud/puppet-openstack_zeromq

I think you can take inspiration from
https://github.com/stackforge/puppet-nova/blob/master/manifests/init.pp#L463
to integrate this backend in our modules. Your code is not really
compliant with how we configure RPC in OpenStack though. You can take
example on RabbitMQ or QPID.

Thanks,

>>
>> Thanks,
>> Harish
>>
>> -- 
>>
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to puppet-openstack+unsubscr...@puppetlabs.com
>> .
> 
> Harish,
> 
> Quick note that we've moved Puppet-OpenStack related conversation to the
> OpenStack development mailing list
> 
> Thank you so much for this contribution - it is certainly much
> appreciated. At this time, as I understand it, we are only hosting the
> OpenStack-specific modules (e.g. Nova, Neutron, etc.).
> 
> While someone very well might want to use your module for deploying
> OpenStack, I think it would be treated in the same way as our other
> supporting modules (e.g. MySQL, RabbitMQ, etc.) - which is that they
> would live under your (or your company's namespace).
> 
> Do you feel comfortable publishing this module on the Puppet Forge? I
> would be more than happy to help with that process if necessary.
> 
> Regards,
> 
> Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Emilien Macchi



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

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Duncan Thomas]

+1 without hesitation
On 22 May 2015 16:36, "Mike Perez"  wrote:

> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
>
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
>
> Contributions:
> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
>
> 30/90 day review stats:
> http://stackalytics.com/report/contribution/cinder-group/30
> http://stackalytics.com/report/contribution/cinder-group/90
>
> As new contributors step up to help in the project, some move onto
> other things. I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
>
> Cinder core, please reply with a +1 for approval. This will be left
> open until May 29th. Assuming there are no objections, this will go
> forward after voting is closed.
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] OpenStack Puppet modules boilerplate

[Sebastien Badia]

Hi,

During the Puppet session (during the Vancouver summit), we talked about a 
boilerplate
OpenStack Puppet modules for the new ones. Especially about « compliant » and 
approved
puppet modules.

We talked about puppet-modules-skeleton (using the gareth example¹) and tried
using skeleton for our needs² but unfortunately puppet module and skeleton
boilerplate doesn't fit because we can't template a directory name or
a file name (puppet module generate use only erb).

Spredzy therefore proposed cookiecutter (this tool is also used by OpenStack³),
and it works very smoothly :-) 


For a new OpenStack puppet module, just run:

 $ cookiecutter 
https://github.com/enovance/cookiecutter-openstack-puppet-modules.git

And after a bit of msync, voila!

I'll migrate enovance/cookiecutter-openstack-puppet-modules to stackforge. The 
repo name is OK for you? Or you prefer a name starting by puppet- something in

order to easily catch-up all our modules?

Yanis, Seb

¹https://github.com/garethr/puppet-module-skeleton
²https://github.com/enovance/puppet-module-skeleton
³https://github.com/openstack-dev/cookiecutter
--
Sebastien Badia


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

[openstack-dev] [cinder] Some Changes to Cinder Core

[Mike Perez]

This is long overdue, but it gives me great pleasure to nominate Sean
McGinnis for
Cinder core.

Reviews:
https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z

Contributions:
https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z

30/90 day review stats:
http://stackalytics.com/report/contribution/cinder-group/30
http://stackalytics.com/report/contribution/cinder-group/90

As new contributors step up to help in the project, some move onto
other things. I would like to recognize Avishay Traeger for his
contributions, and now
unfortunately departure from the Cinder core team.

Cinder core, please reply with a +1 for approval. This will be left
open until May 29th. Assuming there are no objections, this will go
forward after voting is closed.

--
Mike Perez

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

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Fox, Kevin M]

I believe that trove still needs the multi tenant isolation of a multi tenant 
message queue due to the fact that the vm runs in the tenant, and the tenant 
can then force a reboot, go to the console, root it, and inject messages at 
queues destened for other tenants vm's. And there are other routes too.

This is a major problem, and I think our site is going to have to strongly 
consider uninstalling trove until fixed.

Thanks,
Kevin


From: Zane Bitter
Sent: Friday, May 22, 2015 12:34:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my notes

On 22/05/15 11:48, Amrith Kumar wrote:
> I’m posting this to the mailing list to summarize my notes from a
> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
> multi-tenant messaging and how it may be applicable to a number of projects.
>
> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
> notes and observations after the meeting and how they relate
> specifically to Trove. I don’t claim to speak for Trove, other
> contributors to Trove, other projects who were at the meeting, for
> zaqar, etc., etc.,
>
> After the meeting I think I have a slightly better understanding of what
> Zaqar is but I am still not entirely sure. As best as I can tell, it is
> a lightweight, keystone authenticated, multi-tenant messaging system.

I'm not sure what 'lightweight' means in this context. I'd describe it
as a keystone-authenticated multi-tenant reliable messaging system a la
Amazon SQS.

> I
> am still a little troubled that of the many people in the room who were
> knowledgeable of zaqar, there appeared to be some disagreement on how
> best to describe or explain the project.

I don't think there's any disagreement. It just seems to be hard to
explain to people, because everyone instinctively wants to compare it to
Rabbit, which is a completely different thing with completely different
use cases. IMHO part of the problem has been that folks have been
reluctant to name SQS specifically, and so we end up talking elliptically.

> I learned that users of zaqar can authenticate with keystone and then
> interact with zaqar, and pass messages using it. I learned also that
> zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
> zaquar as I had thought it was.
>
> It became clear that the underlying transport in zaqar is not based on
> an existing AMQP service, rather zaqar is a “from the ground up”
> implementation. This scares me (a lot).

Yes, literally every person who has ever heard of Zaqar complains about
this and it's getting a little boring. It's irrelevant because Zaqar is
not a replacement for AMQP, it's a replacement for SQS.

> I gather there is currently no oslo.messaging integration with zaqar;

Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
messaging.

(Although that could be an interesting idea, it's another discussion
altogether.)

> for Trove to use zaqar we would have to either (a) abandon
> oslo.messaging and use zaqar, or (b) build in smarts within Trove to
> determine at run time whether we are using zaqar or o.m and implement
> code in Trove to handle the differences between them if any.
>
> It wasn’t clear to me after the meeting what differences there may be
> with Trove; one which was alluded to was the inability to do a
> synchronous (call()) style message and the statement was that this was
> something that “could be built into a driver”.

Where Zaqar really provides the biggest benefit is sending the message
from the cloud to the user/application (since it can be authenticated by
Keystone). IMHO the ideal scenario would be that messages from Trove (or
whatever) to the VM would go over Zaqar, and for messages in the other
direction would just go straight to the Trove (or whatever) API. The
problem is that Keystone's authorisation capabilities are not sufficient
to handle this at the moment. One thing that should be possible in a
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.

> It wasn’t clear to me what scale zaqar has been run at and whether
> anyone has in fact deployed and run zaqar at scale, and whether it has
> been battle hardened the way a service like RabbitMQ has. While I hear
> from many that RabbitMQ is a nightmare to scale and manage, I realize
> that it does in fact have a long history of deployments at scale.

I believe that Rackspace deployed it?

> We discussed some of the assumptions being made in the conversation
> relative to the security of the various parties to the communication on
> the existing rabbit message queue and at the conclusion of the meeting I
> believe we left things as below.
>
> (a)Zaqar would be more appealing if it had a simple oslo.messaging
> driver and an easier path to integration by client projects like Trove.
> The rip-and-replace option put a certain damper on the enthusiasm

So the key point here is that Tr

Re: [openstack-dev] [Manila] Question to driver maintainers

[yang, xing]

Hi Igor,

We can support extending a share without loss of connectivity, but we don’t 
support shrinking.

Thanks,
Xing


From: Jason Bishop [mailto:jason.bis...@gmail.com]
Sent: Thursday, May 21, 2015 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila] Question to driver maintainers

Hi Igor, Hitachi SOP drive can support share extending online without 
disruption.

cheers
jason


On Mon, May 18, 2015 at 1:15 AM, Igor Malinovskiy 
mailto:imalinovs...@mirantis.com>> wrote:

Hello, everyone!

My letter is mainly addressed to driver maintainers, but could be interesting 
to everybody.


As you probably know, on Kilo midcycle meetup we discussed share resize 
functionality (extend and shrink) and I already have implemented 'extend' API 
in Generic driver (https://review.openstack.org/182383/). After implementation 
review we

noticed that some backends are able to resize a share without causing 
disruptions, but others might only be able to do it disruptively (Generic 
driver case).


So I want to ask driver maintainers here:

Will your driver be able to do share extending without loss of connectivity?


Depending on your answers, we will handle this situation differently.


Best regards,

Igor Malinovskiy (IRC: u_glide)
Manila Core Team

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

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

[openstack-dev] [Nova] Using depends-on for patches which require an approved spec

[Michael Still]

Hey,

it would be cool if devs posting changes for nova which depend on us
approving their spec could use Depends-On to make sure their code
doesn't land until the spec does.

Just my random thought for the day.

Michael

-- 
Rackspace Australia

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

[openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Nikhil Komawar]

Hi all,

tl;dr; Artifacts IS staying in Glance.

1. We had a nice discussion at the contributors' meet-up at the
   Vancouver summit this morning. After weighing in many possibilities
   and evolution of the Glance program, we have decided to go ahead
   with the Artifacts implementation within Glance program under the
   EXPERIMENTAL v3 API.
2. The effort would primarily be conducted as a sub-team-like structure
   within the program and the co-coordinators and drivers of the
   necessary Artifacts features would be given core-reviewer status
   temporarily with an informal agreement to merge code that is only
   related to Artifacts.
3. The entire Glance team would give reviews as time and priorities
   permit. The approval (+A/+WorkFlow) of any code within the program
   would need to come from core-reviewers who are not temporarily
   authorized. The list of such individuals and updated time-line would
   be documented in phases during the course of Liberty cycle.
4. We will continue to evaluate & update the governance, maturity of
   the code and future plans for the v1, v2 and v3 Glance APIs as time
   progresses. However, for now we are aiming to integrate all of
   Glance (specifically Images) as Artifacts in the v3 API.

Special thanks to Flavio for providing DefCore and TC perspective as 
well as initializing this discussion. Also, thanks to Stuart McLaren and 
Brian Rosmaita for giving us thoughtful veteran feedback. The entire 
team did a great job at putting all their questions and concerns 
amicably on the table and came to a good understanding of the plan and 
level of commitment.


All the best to the Project SearchLight team who have decided to start 
ElasticSearch based development for search functionality in OpenStack as 
a separate program and would be porting respective code out of Glance. 
Glance team would help co-ordinate this porting effort in order to avoid 
destabilizing Images and MetaDefs code-bases.


This also means we will re-evaluate some of the existing spec proposals 
and most likely not ask people for radical changes in their approach. 
This first phase of the Liberty cycle would focus on seeing the 
Experimental Artifacts API through. We will also focus on stability 
aspects of the Images (v1 & v2) related features. The second phase 
priorities would be decided at the mid-cycle meet-up (details to come 
out soon).


Feel free to ask me questions on IRC or via email.

Cheers,
Nikhil

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

Re: [openstack-dev] [nova][heat] sqlalchemy-migrate tool to alembic

[Mike Bayer]

OK, have just gotten off a chat with the folks at summit.

I am glad that I've managed to get my concerns about this approach out 
there.   For people reading my notes here, I've gotten the answer to my 
question about how database access code is written for a system that is 
moving from some particular schema structure A to a new one B.


Essentially, supposing we've released "L", and we are now in development 
for "M".  Over the course of M, we are adding new objects, e.g. tables, 
columns; let's call these M1, M2, M3.   These objects are meant to 
replace older objects in L, say L1, L2, L3.


As M is being developed, at all times the model and database access 
layer must consider both of L1, L2, L3, and M1, M2, M3, at the same 
time.  Meaning, the notion of schema migrations as something you commit 
and at which point you can cleanly just change your model is gone.  The 
model needs to be able to load data from the L1/L2/L3 objects and ensure 
that it gets copied to M1, M2, M3, either as the APIs are accessed under 
normal use, or via a "background process" that will move data over from 
L to M.   It is only when the database data is fully moved to M, but 
also when *all database-connected applications* are moved up as well, 
that the "contract" phase can be run.   The "contract" phase will then 
drop every object in the database that is not in the currently running 
model, including any additional objects that were added by the operator.


Now, the approach of having a model that can bridge the gap between two 
schemas, to delay the full migration of changes across, is in fact very 
common in the real world of database applications.   This is a common 
technique that is often necessary.


What is dramatically different in Nova's case is that what is normally 
just a particularly tedious tool one can choose to use in specific 
situations, that of the model that must bridge two different schema 
designs and slowly migrate data, now becomes an absolute hard 
requirement in all cases. It is no longer considered to be tenable 
for developers to decide on a case-by-case basis which kinds of 
migrations are trivial and can safely be run during an "expand" type of 
phase, vs. those that are data- and lock- intensive if done in bulk and 
therefore should be carefully rolled out over time at low scale.


Let me be clear that one of the big things I want to work on is cleaning 
up the model and database access code I see in Nova and many other 
Openstack applications.  Right now it's complicated, slow, and is 
riddled with evidence that people didn't always have a firm grasp of the 
APIs when they wrote it.   But what we are talking about is creating a 
hard link between the complexity of the model/DB access code and the 
ability to make necessary changes and improvements to the schema.   It 
means that every schema change now inflicts verbosity and complexity 
directly into the model and database access logic, not in a 
self-contained, write-once-and-forget-it database migration script 
elsewhere; data migrations and business model access code are to be 
literally merged together most likely into the same function in many 
cases. This is definitely going to make my job of cleaning up, 
simplifying, and vastly improving the performance of this logic that 
much more difficult.   This is the squeeze point within the whole 
approach and it is also the one which the Nova team could offer the 
least specifics on.  While simple things like column transitions 
shouldn't be too terrible, more significant changes like table moves or 
restructurings will be very difficult; and as always, while this might 
be fine for Nova, it definitely is not appropriate for less mature 
Openstack projects just starting out with new schema designs that will 
have a bigger need for periodic refactorings.


The rationale for this hard-edged decision is that all-at-once data 
migrations are slow and place an enormous load on the database, and 
therefore must be banned in all cases, no matter how trivial.   An 
anecdotal reference to some obviously serious outage that occurred 
during a Nova migration was cited as evidence.


I'm generally not in favor of this approach to a problem.   The driving 
philosophy of SQLAlchemy and related tools are one of developer 
empowerment, not of shuttling away database details behind 
one-size-fits-all abstractions that keep developers as far from pointy 
and sharp edges as possible; because the edges aren't as sharp as you 
remember and a good developer is more deft with tools than you think.   
This philosophy is one that I developed over many years working at 
companies and watching how various forms of technical anxiety led to all 
kinds of obtuse, awkward, and sometimes outright byzantine ways of 
operating, all because something a long time ago failed to work as 
expected, and it was therefore banned forever - it was usually my job to 
extricate teams from these ways of thinking and re-acquai

Re: [openstack-dev] [nova][cinder] can we deprecate the volume CLIs in novaclient?

[Matt Riedemann]

On 5/15/2015 9:38 AM, Sean Dague wrote:

On 05/15/2015 12:28 PM, Everett Toews wrote:

On May 15, 2015, at 10:28 AM, John Griffith mailto:john.griffi...@gmail.com>> wrote:




On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann
mailto:mrie...@linux.vnet.ibm.com>> wrote:

 This came up while talking about bug 1454369 [1].  This also came
 up at one point in kilo when we found out the volume CLIs in
 novaclient didn't work at one point and we broke the cells
 devstack exercises job because of it.

 python-novaclient uses cinder API to handle the volume CLI rather
 than going to the nova volume API.  There are issues with this
 because novaclient needs a certain endpoint/service_type setup in
 the service catalog to support cinder v1/v2 APIs (whatever
 devstack sets up today).  novaclient defaults to volume (v1) and
 if you disable that in cinder then novaclient doesn't work because
 it's not using volumev2.

 So like anyone might ask, why doesn't novaclient talk to nova
 volume APIs to do volume thingies and the answer is because the
 nova volume API doesn't handle all of the volume thingies like
 snapshots and volume types.

 So I got to to thinking, why the hell are we still supporting
 volume operations via novaclient anyway?  Isn't that
 cinderclient's job?  Or python-openstackclient's job?  Can't we
 deprecate the volume CLIs in novaclient and tell people to use
 cinderclient instead since it now has version discovery [2] so
 that problem would be handled for us.

 Since we have nova volume APIs maybe we can't remove the volume
 CLIs in novaclient, but could they be limited to just operations
 that the nova API supports and then we make novaclient talk to
 nova volume APIs rather than cinder APIs (because the nova API
 will talk to cinderclient which again has the version discovery
 done for us).

 Or assuming we could deprecate the volume CLIs in novaclient, what
 would the timeline on deprecation be since it's not a server
 project with a 6 month release cycle?  I'm assuming we'd still
 have 6-12 months deprecation on a client like this because of all
 of the tooling potentially written around it.

 [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369
 [2] https://review.openstack.org/#/c/145613/

​I can't speak for the nova folks, however i do think removing the
volume calls from novaclient seems "ok".  It was always sort of left
for compat I think, and not sure any of us really thought about just
removing it.  At this point it probably just introduces confusion and
as you're running into "problems".

Seems like a good plan, and somewhat less confusing.  On a side note,
might be some other *things* in novaclient that we could look at as
well, particularly around networking.  ​


FWIW, this is already underway in jclouds-land. After a lengthy
deprecation period (still ongoing actually), we’ll be removing the Nova
volume calls but obviously keeping the volume attachment stuff.

Both the Nova and Cinder calls have coexisted for over a year with
documentation pointing from Nova to Cinder. The deprecation annotations
handle emitting warnings for the deprecated calls to increase visibility.


Everett, this is actually a different thing.

"nova volume "  does not talk to Nova's volume proxy, it goes
straight to cinder through the service catalog.

Deprecating this part of nova client is probably fine, but it should
have a lengthy deprecation cycle, as it's been like this for a very long
time. It feels like it won't go away before openstack client starts
taking hold anyway.

I think this raises a more important issue of Service Catalog
Standarization. The reason we're in a bind here has as much to do with
the fact that service catalog content isn't standardized for OpenStack
services. If so, having another cinder implementation in novaclient
wouldn't be such a bad thing, and not having to switch cli commands is
pretty handy (all hail our future osc overlords).

Fortunately, we're going to be talking about just this kind of problem
at Summit -
http://libertydesignsummit.sched.org/event/194b2589eca19956cb88ada45e985e29

-Sean



Here is the change for those following along at home:

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

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] Pip 7 released

[Asselin, Ramy]

Rob, thanks for your help. We're all set. We moved our trusted-hosts to 
definitions to the pip.conf [global] section.
Ramy
 

-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: Friday, May 22, 2015 7:26 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Pip 7 released

This is just a heads up, Donald has released pip 7, which includes wheel 
caching that should help reduce developer pain around new tox venvs, amongst 
other things. CI seems happy and green with it (yay), except for 3par, which 
I'm going to see if I can help when they get back on IRC :)

Cheers,
Rob

--
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

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

Re: [openstack-dev] [security] Nominating Mike McCune as Security-Doc Core

[Nathan Kinder]

On 05/19/2015 05:20 PM, Dillon, Nathaniel wrote:
> To the Security and Docs groups as well as other interested parties, 
> 
> I would like to nominate Mike McCune to the Security Guide core. He has been 
> contributing to the Security Guide for about six months now, and he has been 
> a consistent participant improving content and helping new submittors. In 
> addition, he knows the inner workings of the guide, having created and merged 
> for the security guide the chapter on Sahara.
> 
> Please chime in with your agreement, or concerns.

+1!  Mike's work has been great.

-NGK

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

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

Re: [openstack-dev] [zaqar]

[Victoria Martínez de la Cruz]

Hi,

So, what are you trying to do? With guest agent you are referring to Trove
guest agent?

Thanks


El sáb., 16 may. 2015 a las 5:42, Li Tianqing () escribió:

> Hello,
> How can zaqar make guestagent in vm connect to server manager? Can
> someone give one example?
> Thanks.
>
>
>
>
> --
> Best
> Li Tianqing
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Oleg Gelbukh]

Roman,

I'm totally for fixing Nailgun. However, the status of environment is not
simply function of statuses of nodes in it. Ideally, it should depend on
whether appropriate number of nodes of certain roles are in 'ready' status.
For the meantime, it would be enough if environment was set to
'operational' when all nodes in it become 'ready', no matter how they were
deployed (i.e. via Web UI or CLI).

--
Best regards,
Oleg Gelbukh

On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko  wrote:

> Hi folks!
>
> Recently I encountered an issue [1] that the Deploy Changes button in the
> web ui is still active when a provisioning of single node is started using
> the command line client.
> The background for that issue is that the provisioning task does not seem
> to update the cluster status correctly and Nailgun’s API returns it as NEW
> even while some of the node are been provisioned.
>
> The reason for raising this thread in the mailing list is that
> provisioning a node is a feature for developers and basically end-users
> should not do that. What is the best solution for that: fix Nailgun to set
> the correct status, or make this provisioning feature available only for
> developers?
>
> 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
>
>
> - romcheg
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

[Richard Raseley]

Daniel Comnea wrote:

Since i couldn't attend the summit, are there any AIs which needs to
happen/ take place and which i can keep an eye on?


There weren't any action items, which aren't already (in whole or in 
part) in flight as part of their respective product discussions.


From my perspective, a couple of the key bits which came out of the 
discussion were:


* There needs to be a lot of consideration given to the use-case of 
containers as pets, not just as cattle. This is especially important 
from a service provider point of view. People want things like 
live-migration, non-ephemeral storage, etc.


* There is some confusion around what networking models play in what 
ways (e.g. Neutron integration).


* Interest in how Glance is going to solve the issue of 'hierarchical 
images' (for lack of a better term), which is important to some 
container models. This was as coupled with interest in making Glance a 
more generic artifact storage service.


Again, as I understand it these are already known quantities. If anyone 
feels I've misrepresented parts of our discussion here, please let me know.


Regards,

Richard


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

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Zane Bitter]

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.


I'm not sure what 'lightweight' means in this context. I'd describe it 
as a keystone-authenticated multi-tenant reliable messaging system a la 
Amazon SQS.



I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.


I don't think there's any disagreement. It just seems to be hard to 
explain to people, because everyone instinctively wants to compare it to 
Rabbit, which is a completely different thing with completely different 
use cases. IMHO part of the problem has been that folks have been 
reluctant to name SQS specifically, and so we end up talking elliptically.



I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).


Yes, literally every person who has ever heard of Zaqar complains about 
this and it's getting a little boring. It's irrelevant because Zaqar is 
not a replacement for AMQP, it's a replacement for SQS.



I gather there is currently no oslo.messaging integration with zaqar;


Right, Zaqar has never been intended as a replacement for Rabbit in Oslo 
messaging.


(Although that could be an interesting idea, it's another discussion 
altogether.)



for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.


Where Zaqar really provides the biggest benefit is sending the message 
from the cloud to the user/application (since it can be authenticated by 
Keystone). IMHO the ideal scenario would be that messages from Trove (or 
whatever) to the VM would go over Zaqar, and for messages in the other 
direction would just go straight to the Trove (or whatever) API. The 
problem is that Keystone's authorisation capabilities are not sufficient 
to handle this at the moment. One thing that should be possible in a 
shorter time-frame is a pre-signed URL for a Zaqar queue as a return path.



It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.


I believe that Rackspace deployed it?


We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm


So the key point here is that Trove regards the VM running the database 
and the Trove agent as within its own security perimeter. (Whether 
that's appropriate is another debate, but it's up to the Trove 
contributors to decide.) In this case, the ability to authenticate to 
the queue using Keystone provides no real value, so this isn't really a 
use case that requires Zaqar.


The same is not true for other projects, like Heat, Murano and Sahara. 
Whenever the agent is outside the security perimeter, we need an 
authenticated, metered, multi-tenant access method.



(b)Even with an o.m integration, the incremental benefits that zaqar
brought were diminished by the fact that one would still have to operate
an AMQP (Rabbit

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Joe Gordon]

On Fri, May 22, 2015 at 8:48 AM, Amrith Kumar  wrote:

>  I’m posting this to the mailing list to summarize my notes from a
> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
> multi-tenant messaging and how it may be applicable to a number of projects.
>
>
>
> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my notes
> and observations after the meeting and how they relate specifically to
> Trove. I don’t claim to speak for Trove, other contributors to Trove, other
> projects who were at the meeting, for zaqar, etc., etc.,
>
>
>
> After the meeting I think I have a slightly better understanding of what
> Zaqar is but I am still not entirely sure. As best as I can tell, it is a
> lightweight, keystone authenticated, multi-tenant messaging system. I am
> still a little troubled that of the many people in the room who were
> knowledgeable of zaqar, there appeared to be some disagreement on how best
> to describe or explain the project.
>

If we cannot agree on how to explain zaqar, how can projects even think
about adopting it?


>
>
> I learned that users of zaqar can authenticate with keystone and then
> interact with zaqar, and pass messages using it. I learned also that zaqar
> is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t zaquar as
> I had thought it was.
>
>
>
> It became clear that the underlying transport in zaqar is not based on an
> existing AMQP service, rather zaqar is a “from the ground up”
> implementation. This scares me (a lot).
>
>
>
> I gather there is currently no oslo.messaging integration with zaqar; for
> Trove to use zaqar we would have to either (a) abandon oslo.messaging and
> use zaqar, or (b) build in smarts within Trove to determine at run time
> whether we are using zaqar or o.m and implement code in Trove to handle the
> differences between them if any.
>
>
>
> It wasn’t clear to me after the meeting what differences there may be with
> Trove; one which was alluded to was the inability to do a synchronous
> (call()) style message and the statement was that this was something that
> “could be built into a driver”.
>
>
>
> It wasn’t clear to me what scale zaqar has been run at and whether anyone
> has in fact deployed and run zaqar at scale, and whether it has been battle
> hardened the way a service like RabbitMQ has. While I hear from many that
> RabbitMQ is a nightmare to scale and manage, I realize that it does in fact
> have a long history of deployments at scale.
>
>
>
> We discussed some of the assumptions being made in the conversation
> relative to the security of the various parties to the communication on the
> existing rabbit message queue and at the conclusion of the meeting I
> believe we left things as below.
>
>
>
> (a)Zaqar would be more appealing if it had a simple oslo.messaging driver
> and an easier path to integration by client projects like Trove. The
> rip-and-replace option put a certain damper on the enthusiasm
>
> (b)Even with an o.m integration, the incremental benefits that zaqar
> brought were diminished by the fact that one would still have to operate an
> AMQP (RabbitMQ) service for the rest of the infrastructure message passing
> needs unless and until all projects decide to abandon RabbitMQ in favor of
> zaqar
>
> (c)At this time it is likely that there is no net benefit to a project
> like Trove in integrating with zaqar given that the upside is likely
> limited, the downside(s) that we know of are significant, and there is a
> significant unknown risk.
>
>
>
> My thanks to the folks from zaqar for having the session, I certainly
> learnt a lot more about the project, and about openstack.
>
>
>
> Let me conclude where I began, by saying the preceding is not a ‘minutes
> of the meeting’, merely my notes from the meeting.
>
>
>
> Thanks,
>
>
>
> -amrith
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Mike Scherbakov]

OpenStack operator should be provided with an option to just provision
nodes. We want to provide flexibility for sophisticated users, and I
consider this as normal use case. So I disagree that we should treat
provisioning as just developers feature.

For newbies / simplest clouds, we want to keep the easiest way of
installation possible, i.e. just Deploy button. We can claim that we've
succeeded with this once 6-year kid is able to deploy OpenStack with Fuel.

On Fri, May 22, 2015 at 7:33 AM, Roman Prykhodchenko  wrote:

> Hi folks!
>
> Recently I encountered an issue [1] that the Deploy Changes button in the
> web ui is still active when a provisioning of single node is started using
> the command line client.
> The background for that issue is that the provisioning task does not seem
> to update the cluster status correctly and Nailgun’s API returns it as NEW
> even while some of the node are been provisioned.
>
> The reason for raising this thread in the mailing list is that
> provisioning a node is a feature for developers and basically end-users
> should not do that. What is the best solution for that: fix Nailgun to set
> the correct status, or make this provisioning feature available only for
> developers?
>
> 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
>
>
> - romcheg
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [oslo][service] oslo.service puplic repositiry review request

[Davanum Srinivas]

Hi Elena,

This looks good to me.

thanks,
dims

On Thu, May 21, 2015 at 7:38 AM, Elena Ezhova  wrote:
> Hi, all!
>
> As the spec for the graduation of oslo.service [1] is about to merge I have
> created a public repository on github [2] with oslo.service initial version,
> which is the next step in graduation of a library according to [3].
>
> I would like to ask everyone interested to review it so we can proceed with
> the graduation process.
>
> Thanks, Elena
>
>
> [1] https://review.openstack.org/#/c/142659/9
> [2] https://github.com/eezhova/oslo.service
> [3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [nova][oslo] RPC Asynchronous Communication

[Joe Gordon]

On Thu, May 21, 2015 at 8:13 AM, Sahid Orentino Ferdjaoui <
sahid.ferdja...@redhat.com> wrote:

> On Fri, May 08, 2015 at 09:13:59AM -0400, Doug Hellmann wrote:
> > Excerpts from Joe Gordon's message of 2015-05-07 17:43:06 -0700:
> > > On May 7, 2015 2:37 AM, "Sahid Orentino Ferdjaoui" <
> > > sahid.ferdja...@redhat.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The primary point of this expected discussion around asynchronous
> > > > communication is to optimize performance by reducing latency.
> > > >
> > > > For instance the design used in Nova and probably other projects let
> > > > able to operate ascynchronous operations from two way.
> > > >
> > > > 1. When communicate between inter-services
> > > > 2. When communicate to the database
> > > >
> > > > 1 and 2 are close since they use the same API but I prefer to keep a
> > > > difference here since the high level layer is not the same.
> > > >
> > > > From Oslo Messaging point of view we currently have two methods to
> > > > invoke an RPC:
> > > >
> > > >   Cast and Call: The first one is not bloking and will invoke a RPC
> > > > without to wait any response while the second will block the
> > > > process and wait for the response.
> > > >
> > > > The aim is to add new method which will return without to block the
> > > > process an object let's call it "Future" which will provide some
> basic
> > > > methods to wait and get a response at any time.
> > > >
> > > > The benefice from Nova will comes on a higher level:
> > > >
> > > > 1. When communicate between services it will be not necessary to
> block
> > > >the process and use this free time to execute some other
> > > >computations.
> > >
> > > Isn't this what the use of green threads (and eventlet) is supposed to
> > > solve. Assuming my understanding is correct, and we can fix any issues
> > > without adding async oslo.messaging, then adding yet another async
> pattern
> > > seems like a bad thing.
>
> The aim is to be not library specific and avoid to add different and
> custom patterns on the base code each time we want something not
> blocking.
> We can let the well experimented community working in olso messaging
> to maintain that part and as Doug said oslo can use different
> "executors" so we can avoid the requirement of a specific library.
>

I see no problem with nova depending on a specific async library. I am not
keen on adding yet another column to our support matrix.


>
> > Yes, this is what the various executors in the messaging library do,
> > including the eventlet-based executor we use by default.
> >
> > Where are you seeing nova block on RPC calls?
>
> In Nova we use the indirection api to make call to the database by the
> conductor through RPCs.
> By the solution presented we can create async operations to read and
> write from the database.
>
> Olekssi asks me to give an example I will reply to him.
>
> s.
> > Doug
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Demo Video

[Jay Lau]

Cool!

2015-05-22 8:37 GMT-07:00 Adrian Otto :

>  Team,
>
>  In response to excitement about the demo of magnum I showed during our
> Tuesday keynote at the OpenStack Summit in Vancouver, I have made a
> screencast of that same demo, and published it on the Magnum project page:
>
>  https://wiki.openstack.org/wiki/Magnum
>
>  If you want to check out the full Keynote, see the link below [1], and
> if you want to skip right to the part about Magnum, see my blog [2]. Please
> share these videos with your colleagues back home who want to get a crisp
> idea about what Magnum can do today.
>
>  Thanks,
>
>  Adrian
>
>  [1]
> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/taking-risks-how-experimentation-leads-to-breakthroughs
> [2]
> http://adrianotto.com/2015/05/video-vancouver-openstack-keynote-with-magnum-and-kubrnetes/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

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

[openstack-dev] [heat] New alternate meeting time

[Steve Baker]

Heat's current meeting times are Wednesdays 2000 UTC, and 1200 UTC on 
alternate weeks.


Since I can't attend the 1200 UTC time I would like to suggest the new 
alternate time of 0700 UTC.


http://www.timeanddate.com/worldclock/meetingdetails.html?year=2015&month=5&day=27&hour=7&min=0&sec=0&p1=22&p2=1038&p3=33&p4=166&p5=676&p6=136

This time looks bad for the Americas, but should be reasonable for 
everybody else in the world, so I'm hoping for a decent turnout.


The next heat meeting is the alternate time, so I'll see you on 
Wednesday 27th at 0700 UTC.


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

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

[Steven Dake (stdake)]

Debo,

The Sahara cats are having a contributors meetup right now in room 218. @ ODS.  
I have prior commitments so won’t be able to attend, but perhaps some of the 
cognitive folks could make the meetup there.

Sergey,

If the Sahara contributors plan on walking the city tonight, feel free to send 
me info off-list and I’ll try to make it.

Regards
-steve


From: Sergey Lukjanov mailto:slukja...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, May 22, 2015 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project 
to deliver Machine Learning as a Service for OpenStack

So, in case if Cognitive will use Sahara to create big data clusters - then it 
sounds ok.

On Fri, May 22, 2015 at 8:54 AM, Debojyoti Dutta 
mailto:ddu...@gmail.com>> wrote:
One more thing and a typo in my mail  -  we would be happy to point folks to an 
very early version (in Django) we prototyped and opened up recently.

thx
debo



On Fri, May 22, 2015 at 8:48 AM, Debojyoti Dutta 
mailto:ddu...@gmail.com>> wrote:
Hi Sergey

Thanks a lot for your interest. The bare bones API proposal is up on the wiki 
page http://wiki.openstack.org/Cognitive

Sahara is about deploying and managing big data workloads like hadoop, spark 
etc. Cognitive is about a simple API to do predictive analytics, learning, data 
science workflow etc etc. Thus the goals are different. AWS has Elastic 
MapReduce (in the same space as Sahara) and also AWS Machine Learning 
(http://aws.amazon.com/machine-learning/) for which there is no parallel. 
Should we point them to our internal 1st version of Cognitive on our github 
which we opened.


If it requires to use big data toolchains to do our job, we will definitely 
leverage Sahara for that, and not replicate the good work done in Sahara. Our 
primary goal is to build (within the community) a simple machine learning API 
(and a service) that abstracts the pain of data science for the app developer.


thx

debo


PS: FWIW  I am at the summit till tonight so we could catch up here.



On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov 
mailto:slukja...@mirantis.com>> wrote:
Hi,

as there is no any details on the project yet done, if this project will deploy 
ML frameworks it'll be direct duplication of Sahara's functionality (we already 
support HDP and CDH deployments and they are provided tons of tools for ML). 
So, I think that it could be built on top of Sahara or even as part of Sahara 
probably. I'd like to propose you to take a deeper look on Sahara and avoid 
duplicating it.

Thanks.

On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta 
mailto:ddu...@gmail.com>> wrote:
Hi Salvatore

Thanks a lot for your comments.

Timing: Yes it is time to do this! The nature of applications running on clouds 
is indeed changing.

Initial group: We asked around for folks interested and we got a lot more 
people than we expected. The idea is to get something out there in a stack 
forge project and build something good. This group already has people who have 
built things like this already in the past. Hence confident about the success.

Participation: We want this to be inclusive from scratch independent of who is 
a PTL or a contributor or merely a curious individual to give us ideas :) The 
community will get it right. Maybe I should have clarified that these are the 
members interested in seeing this happen.

Wiki page: The wiki page will be ready in 1-2 days. Also we would like to have 
a discussion during the summit to see what we should build in the community. 
Would be delighted to get your thoughts.

Services: Some of the services this could provide:
* create experiments: define data sources, train models, then perform 
classification, clustering, data cleaning etc.
* have experiment templates that can be reused
* have an editor (maybe a horizon plugin) to drag and drop the workflow and 
generate an API that when called from an app would provide results
* ML primitives that could be targeted initially: 1) classification  2) 
clustering 3) Anomaly detection

thx
debo

On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando 
mailto:sorla...@nicira.com>> wrote:

On 15 May 2015 at 00:19, Debojyoti Dutta 
mailto:ddu...@gmail.com>> wrote:
Hi!

It is a great pleasure to announce the development of a new project called 
Cognitive.  Cognitive provides Machine Learning [1] as a Service that enables 
operators to offer next generation data science based services on top of their 
OpenStack Clouds.

I was indeed wondering when "Machine Learning as a Service" would come up...

This project will begin as a StackForge project baed upon an empty cookiecutter 
[2] repo.  The repos to work in are:
Server: https://github.com/stackforge/cognitive
Client: https://github.com/stackforge/python-cognitiveclient

Please joi

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

[Sergey Lukjanov]

So, in case if Cognitive will use Sahara to create big data clusters - then
it sounds ok.

On Fri, May 22, 2015 at 8:54 AM, Debojyoti Dutta  wrote:

> One more thing and a typo in my mail  -  we would be happy to point folks
> to an very early version (in Django) we prototyped and opened up recently.
>
> thx
> debo
>
>
>
> On Fri, May 22, 2015 at 8:48 AM, Debojyoti Dutta  wrote:
>
>> Hi Sergey
>>
>> Thanks a lot for your interest. The bare bones API proposal is up on the
>> wiki page http://wiki.openstack.org/Cognitive
>>
>> Sahara is about deploying and managing big data workloads like hadoop,
>> spark etc. Cognitive is about a simple API to do predictive analytics,
>> learning, data science workflow etc etc. Thus the goals are different. AWS
>> has Elastic MapReduce (in the same space as Sahara) and also AWS Machine
>> Learning (http://aws.amazon.com/machine-learning/) for which there is no
>> parallel. Should we point them to our internal 1st version of Cognitive on
>> our github which we opened.
>>
>> If it requires to use big data toolchains to do our job, we will
>> definitely leverage Sahara for that, and not replicate the good work done
>> in Sahara. Our primary goal is to build (within the community) a simple
>> machine learning API (and a service) that abstracts the pain of data
>> science for the app developer.
>>
>>
>> thx
>>
>> debo
>>
>>
>> PS: FWIW  I am at the summit till tonight so we could catch up here.
>>
>>
>>
>> On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov 
>> wrote:
>>
>>> Hi,
>>>
>>> as there is no any details on the project yet done, if this project will
>>> deploy ML frameworks it'll be direct duplication of Sahara's functionality
>>> (we already support HDP and CDH deployments and they are provided tons of
>>> tools for ML). So, I think that it could be built on top of Sahara or even
>>> as part of Sahara probably. I'd like to propose you to take a deeper look
>>> on Sahara and avoid duplicating it.
>>>
>>> Thanks.
>>>
>>> On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta 
>>> wrote:
>>>
 Hi Salvatore

 Thanks a lot for your comments.

 Timing: Yes it is time to do this! The nature of applications running
 on clouds is indeed changing.

 Initial group: We asked around for folks interested and we got a lot
 more people than we expected. The idea is to get something out there in a
 stack forge project and build something good. This group already has people
 who have built things like this already in the past. Hence confident about
 the success.

 Participation: We want this to be inclusive from scratch independent of
 who is a PTL or a contributor or merely a curious individual to give us
 ideas :) The community will get it right. Maybe I should have clarified
 that these are the members interested in seeing this happen.

 Wiki page: The wiki page will be ready in 1-2 days. Also we would like
 to have a discussion during the summit to see what we should build in the
 community. Would be delighted to get your thoughts.

 Services: Some of the services this could provide:
 * create experiments: define data sources, train models, then perform
 classification, clustering, data cleaning etc.
 * have experiment templates that can be reused
 * have an editor (maybe a horizon plugin) to drag and drop the workflow
 and generate an API that when called from an app would provide results
 * ML primitives that could be targeted initially: 1) classification  2)
 clustering 3) Anomaly detection

 thx
 debo

 On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando >>> > wrote:

>
> On 15 May 2015 at 00:19, Debojyoti Dutta  wrote:
>
>> Hi!
>>
>> It is a great pleasure to announce the development of a new project
>> called Cognitive.  Cognitive provides Machine Learning [1] as a Service
>> that enables operators to offer next generation data science based 
>> services
>> on top of their OpenStack Clouds.
>>
>
> I was indeed wondering when "Machine Learning as a Service" would come
> up...
>
>
>> This project will begin as a StackForge project baed upon an empty
>> cookiecutter [2] repo.  The repos to work in are:
>> Server: https://github.com/stackforge/cognitive
>> Client: https://github.com/stackforge/python-cognitiveclient
>>
>> Please join us via iRC on #openstack-cognitive on freenode.
>>
>> We will be holding a doodle poll to select times for our first
>> meeting the week after summit.  This doodle poll will close May 24th and
>> meeting times will be announced on the mailing list at that time.  At our
>> first IRC meeting, we will draft additional core team members. We would
>> like to invite interested individuals to join this exciting new 
>> development
>> effort!
>>
>
> From my little experience, "drafting" core members

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

[Debojyoti Dutta]

One more thing and a typo in my mail  -  we would be happy to point folks
to an very early version (in Django) we prototyped and opened up recently.

thx
debo



On Fri, May 22, 2015 at 8:48 AM, Debojyoti Dutta  wrote:

> Hi Sergey
>
> Thanks a lot for your interest. The bare bones API proposal is up on the
> wiki page http://wiki.openstack.org/Cognitive
>
> Sahara is about deploying and managing big data workloads like hadoop,
> spark etc. Cognitive is about a simple API to do predictive analytics,
> learning, data science workflow etc etc. Thus the goals are different. AWS
> has Elastic MapReduce (in the same space as Sahara) and also AWS Machine
> Learning (http://aws.amazon.com/machine-learning/) for which there is no
> parallel. Should we point them to our internal 1st version of Cognitive on
> our github which we opened.
>
> If it requires to use big data toolchains to do our job, we will
> definitely leverage Sahara for that, and not replicate the good work done
> in Sahara. Our primary goal is to build (within the community) a simple
> machine learning API (and a service) that abstracts the pain of data
> science for the app developer.
>
>
> thx
>
> debo
>
>
> PS: FWIW  I am at the summit till tonight so we could catch up here.
>
>
>
> On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov 
> wrote:
>
>> Hi,
>>
>> as there is no any details on the project yet done, if this project will
>> deploy ML frameworks it'll be direct duplication of Sahara's functionality
>> (we already support HDP and CDH deployments and they are provided tons of
>> tools for ML). So, I think that it could be built on top of Sahara or even
>> as part of Sahara probably. I'd like to propose you to take a deeper look
>> on Sahara and avoid duplicating it.
>>
>> Thanks.
>>
>> On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta 
>> wrote:
>>
>>> Hi Salvatore
>>>
>>> Thanks a lot for your comments.
>>>
>>> Timing: Yes it is time to do this! The nature of applications running on
>>> clouds is indeed changing.
>>>
>>> Initial group: We asked around for folks interested and we got a lot
>>> more people than we expected. The idea is to get something out there in a
>>> stack forge project and build something good. This group already has people
>>> who have built things like this already in the past. Hence confident about
>>> the success.
>>>
>>> Participation: We want this to be inclusive from scratch independent of
>>> who is a PTL or a contributor or merely a curious individual to give us
>>> ideas :) The community will get it right. Maybe I should have clarified
>>> that these are the members interested in seeing this happen.
>>>
>>> Wiki page: The wiki page will be ready in 1-2 days. Also we would like
>>> to have a discussion during the summit to see what we should build in the
>>> community. Would be delighted to get your thoughts.
>>>
>>> Services: Some of the services this could provide:
>>> * create experiments: define data sources, train models, then perform
>>> classification, clustering, data cleaning etc.
>>> * have experiment templates that can be reused
>>> * have an editor (maybe a horizon plugin) to drag and drop the workflow
>>> and generate an API that when called from an app would provide results
>>> * ML primitives that could be targeted initially: 1) classification  2)
>>> clustering 3) Anomaly detection
>>>
>>> thx
>>> debo
>>>
>>> On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando 
>>> wrote:
>>>

 On 15 May 2015 at 00:19, Debojyoti Dutta  wrote:

> Hi!
>
> It is a great pleasure to announce the development of a new project
> called Cognitive.  Cognitive provides Machine Learning [1] as a Service
> that enables operators to offer next generation data science based 
> services
> on top of their OpenStack Clouds.
>

 I was indeed wondering when "Machine Learning as a Service" would come
 up...


> This project will begin as a StackForge project baed upon an empty
> cookiecutter [2] repo.  The repos to work in are:
> Server: https://github.com/stackforge/cognitive
> Client: https://github.com/stackforge/python-cognitiveclient
>
> Please join us via iRC on #openstack-cognitive on freenode.
>
> We will be holding a doodle poll to select times for our first meeting
> the week after summit.  This doodle poll will close May 24th and meeting
> times will be announced on the mailing list at that time.  At our first 
> IRC
> meeting, we will draft additional core team members. We would like to
> invite interested individuals to join this exciting new development 
> effort!
>

 From my little experience, "drafting" core members before even actually
 having a code base has drawbacks. Also, it seems the initial starting team
 is already large enough for ensuring support for 1 or 2 release cycle.


>
>

> Please commit your schedule in the doodle poll here:
> http://do

Re: [openstack-dev] [Nova][libvirt] Understand why we lookup libvirt domains by instance name

[Andrew Laski]

On 05/22/15 at 10:16am, Deepak Shetty wrote:

On Fri, May 22, 2015 at 5:19 AM, Mathieu Gagné  wrote:


On 2015-05-21 4:18 PM, Chris Friesen wrote:
>>>
>>
>> I guess it's for the reason I mentioned above:
>>
>> To not break all OpenStack installations on Earth running with default
>> config values.
>>
>
> So that's not breaking *upgrades* of all OpenStack installations with
> default config values, which is a slightly different thing.
>

Yes it will. Try to change instance_template_name and manage existing
instances. You won't be able.

The above scenario is the same as upgrading OpenStack Nova and having
instance_template_name changes its default value. Unless someone patches
Nova to use the instance UUID instead of its name to find it in libvirt.



Novice question:
  For each instance I believe we store the name (instance-xx) and uuid
in
the DB ? If yes, then can't nova lookup using uuid given the name or vice
versa
since the mapping to name - uuid is possible from DB ?


The name is not stored in the database, or at all.  It is generated by a 
config option template on each database access.  So if the config option 
is changed all instance names will change.







--
Mathieu

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




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



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

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

[Debojyoti Dutta]

Hi Sergey

Thanks a lot for your interest. The bare bones API proposal is up on the
wiki page http://wiki.openstack.org/Cognitive

Sahara is about deploying and managing big data workloads like hadoop,
spark etc. Cognitive is about a simple API to do predictive analytics,
learning, data science workflow etc etc. Thus the goals are different. AWS
has Elastic MapReduce (in the same space as Sahara) and also AWS Machine
Learning (http://aws.amazon.com/machine-learning/) for which there is no
parallel. Should we point them to our internal 1st version of Cognitive on
our github which we opened.

If it requires to use big data toolchains to do our job, we will definitely
leverage Sahara for that, and not replicate the good work done in Sahara.
Our primary goal is to build (within the community) a simple machine
learning API (and a service) that abstracts the pain of data science for
the app developer.


thx

debo


PS: FWIW  I am at the summit till tonight so we could catch up here.



On Tue, May 19, 2015 at 2:16 PM, Sergey Lukjanov 
wrote:

> Hi,
>
> as there is no any details on the project yet done, if this project will
> deploy ML frameworks it'll be direct duplication of Sahara's functionality
> (we already support HDP and CDH deployments and they are provided tons of
> tools for ML). So, I think that it could be built on top of Sahara or even
> as part of Sahara probably. I'd like to propose you to take a deeper look
> on Sahara and avoid duplicating it.
>
> Thanks.
>
> On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta  wrote:
>
>> Hi Salvatore
>>
>> Thanks a lot for your comments.
>>
>> Timing: Yes it is time to do this! The nature of applications running on
>> clouds is indeed changing.
>>
>> Initial group: We asked around for folks interested and we got a lot more
>> people than we expected. The idea is to get something out there in a stack
>> forge project and build something good. This group already has people who
>> have built things like this already in the past. Hence confident about the
>> success.
>>
>> Participation: We want this to be inclusive from scratch independent of
>> who is a PTL or a contributor or merely a curious individual to give us
>> ideas :) The community will get it right. Maybe I should have clarified
>> that these are the members interested in seeing this happen.
>>
>> Wiki page: The wiki page will be ready in 1-2 days. Also we would like to
>> have a discussion during the summit to see what we should build in the
>> community. Would be delighted to get your thoughts.
>>
>> Services: Some of the services this could provide:
>> * create experiments: define data sources, train models, then perform
>> classification, clustering, data cleaning etc.
>> * have experiment templates that can be reused
>> * have an editor (maybe a horizon plugin) to drag and drop the workflow
>> and generate an API that when called from an app would provide results
>> * ML primitives that could be targeted initially: 1) classification  2)
>> clustering 3) Anomaly detection
>>
>> thx
>> debo
>>
>> On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando 
>> wrote:
>>
>>>
>>> On 15 May 2015 at 00:19, Debojyoti Dutta  wrote:
>>>
 Hi!

 It is a great pleasure to announce the development of a new project
 called Cognitive.  Cognitive provides Machine Learning [1] as a Service
 that enables operators to offer next generation data science based services
 on top of their OpenStack Clouds.

>>>
>>> I was indeed wondering when "Machine Learning as a Service" would come
>>> up...
>>>
>>>
 This project will begin as a StackForge project baed upon an empty
 cookiecutter [2] repo.  The repos to work in are:
 Server: https://github.com/stackforge/cognitive
 Client: https://github.com/stackforge/python-cognitiveclient

 Please join us via iRC on #openstack-cognitive on freenode.

 We will be holding a doodle poll to select times for our first meeting
 the week after summit.  This doodle poll will close May 24th and meeting
 times will be announced on the mailing list at that time.  At our first IRC
 meeting, we will draft additional core team members. We would like to
 invite interested individuals to join this exciting new development effort!

>>>
>>> From my little experience, "drafting" core members before even actually
>>> having a code base has drawbacks. Also, it seems the initial starting team
>>> is already large enough for ensuring support for 1 or 2 release cycle.
>>>
>>>


>>>
 Please commit your schedule in the doodle poll here:
 http://doodle.com/drrka5tgbwpbfbxy

 Initial core team: Steven Dake, Aparupa Das Gupa, Debo~ Dutta, Johnu
 George,  Kyle Mestery, Sarvesh Ranjan, Ralf Rantzau, Komei Shimamura, Marc
 Solanas, Manoj Sharma, Yathi Udupi, Kai Zhang.

>>>
>>> Hey! What's the Neutron PTL doing there? Sorry we need his reviews we
>>> can't loan it to you!
>>>
>>>

 A little bit about Co

[openstack-dev] meeting with the zaqar team at summit; my notes

[Amrith Kumar]

I'm posting this to the mailing list to summarize my notes from a meeting at 
5pm yesterday at Summit relative to Zaqar and lightweight multi-tenant 
messaging and how it may be applicable to a number of projects.

I'll begin by saying these are not 'minutes' of a meeting, merely my notes and 
observations after the meeting and how they relate specifically to Trove. I 
don't claim to speak for Trove, other contributors to Trove, other projects who 
were at the meeting, for zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what Zaqar 
is but I am still not entirely sure. As best as I can tell, it is a 
lightweight, keystone authenticated, multi-tenant messaging system. I am still 
a little troubled that of the many people in the room who were knowledgeable of 
zaqar, there appeared to be some disagreement on how best to describe or 
explain the project.

I learned that users of zaqar can authenticate with keystone and then interact 
with zaqar, and pass messages using it. I learned also that zaqar is spelt with 
a 'q' that is not followed by a 'u'. i.e. it isn't zaquar as I had thought it 
was.

It became clear that the underlying transport in zaqar is not based on an 
existing AMQP service, rather zaqar is a "from the ground up" implementation. 
This scares me (a lot).

I gather there is currently no oslo.messaging integration with zaqar; for Trove 
to use zaqar we would have to either (a) abandon oslo.messaging and use zaqar, 
or (b) build in smarts within Trove to determine at run time whether we are 
using zaqar or o.m and implement code in Trove to handle the differences 
between them if any.

It wasn't clear to me after the meeting what differences there may be with 
Trove; one which was alluded to was the inability to do a synchronous (call()) 
style message and the statement was that this was something that "could be 
built into a driver".

It wasn't clear to me what scale zaqar has been run at and whether anyone has 
in fact deployed and run zaqar at scale, and whether it has been battle 
hardened the way a service like RabbitMQ has. While I hear from many that 
RabbitMQ is a nightmare to scale and manage, I realize that it does in fact 
have a long history of deployments at scale.

We discussed some of the assumptions being made in the conversation relative to 
the security of the various parties to the communication on the existing rabbit 
message queue and at the conclusion of the meeting I believe we left things as 
below.


(a)Zaqar would be more appealing if it had a simple oslo.messaging driver and 
an easier path to integration by client projects like Trove. The 
rip-and-replace option put a certain damper on the enthusiasm

(b)Even with an o.m integration, the incremental benefits that zaqar brought 
were diminished by the fact that one would still have to operate an AMQP 
(RabbitMQ) service for the rest of the infrastructure message passing needs 
unless and until all projects decide to abandon RabbitMQ in favor of zaqar

(c)At this time it is likely that there is no net benefit to a project like 
Trove in integrating with zaqar given that the upside is likely limited, the 
downside(s) that we know of are significant, and there is a significant unknown 
risk.

My thanks to the folks from zaqar for having the session, I certainly learnt a 
lot more about the project, and about openstack.

Let me conclude where I began, by saying the preceding is not a 'minutes of the 
meeting', merely my notes from the meeting.

Thanks,

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

[openstack-dev] [Magnum] Demo Video

[Adrian Otto]

Team,

In response to excitement about the demo of magnum I showed during our Tuesday 
keynote at the OpenStack Summit in Vancouver, I have made a screencast of that 
same demo, and published it on the Magnum project page:

https://wiki.openstack.org/wiki/Magnum

If you want to check out the full Keynote, see the link below [1], and if you 
want to skip right to the part about Magnum, see my blog [2]. Please share 
these videos with your colleagues back home who want to get a crisp idea about 
what Magnum can do today.

Thanks,

Adrian

[1] 
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/taking-risks-how-experimentation-leads-to-breakthroughs
[2] 
http://adrianotto.com/2015/05/video-vancouver-openstack-keynote-with-magnum-and-kubrnetes/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cue] contributors meetup

[Vipul Sabhaya]

The Cue team will be crashing the Designate contributors meetup Friday at
1:20pm, in room 214.

Come find us there!

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

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

[Roman Prykhodchenko]

Hi folks!

Recently I encountered an issue [1] that the Deploy Changes button in the web 
ui is still active when a provisioning of single node is started using the 
command line client.
The background for that issue is that the provisioning task does not seem to 
update the cluster status correctly and Nailgun’s API returns it as NEW even 
while some of the node are been provisioned.

The reason for raising this thread in the mailing list is that provisioning a 
node is a feature for developers and basically end-users should not do that. 
What is the best solution for that: fix Nailgun to set the correct status, or 
make this provisioning feature available only for developers?

1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Pip 7 released

[Robert Collins]

This is just a heads up, Donald has released pip 7, which includes
wheel caching that should help reduce developer pain around new tox
venvs, amongst other things. CI seems happy and green with it (yay),
except for 3par, which I'm going to see if I can help when they get
back on IRC :)

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [TripleO] HA CI job is green, please consider it when merging patches

[Robert Collins]

On 22 May 2015 at 20:49, Jiří Stránský  wrote:
> Hi all,
>
> after an epic battle with bugs this week, we have a passing CI job for HA.
>
> Looking at the jobs which ran during last night, the success rate is decent
> (14 all-green runs vs. just 1 run where HA job was the sole CI failure).
>
> I'm a bit reluctant still to say "let's make it voting" right now, but i
> think we should be heading that way gradually. If you see a failed HA CI job
> from now on, there's some chance it points out some real issue. Please try
> to go through the logs before overriding its vote and merging a patch with
> red HA CI. If the patch in question is not critical with regards to time,
> recheck is an option :)

Awesome.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [TripleO] HA CI job is green, please consider it when merging patches

[Hugh Brock]

Jirka, this is amazing work. Thanks to you, Giulio, Yanis, and everyone else 
who made it happen.

Now, on to network management... :) ...

Sent from my mobile, please pardon the top posting.

From: Jiří Stránský
Sent: May 22, 2015 1:50 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [TripleO] HA CI job is green, please consider it when 
merging patches

Hi all,

after an epic battle with bugs this week, we have a passing CI job for HA.

Looking at the jobs which ran during last night, the success rate is 
decent (14 all-green runs vs. just 1 run where HA job was the sole CI 
failure).

I'm a bit reluctant still to say "let's make it voting" right now, but i 
think we should be heading that way gradually. If you see a failed HA CI 
job from now on, there's some chance it points out some real issue. 
Please try to go through the logs before overriding its vote and merging 
a patch with red HA CI. If the patch in question is not critical with 
regards to time, recheck is an option :)


Thanks

Jirka

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

[openstack-dev] [TripleO] HA CI job is green, please consider it when merging patches

[Jiří Stránský]

Hi all,

after an epic battle with bugs this week, we have a passing CI job for HA.

Looking at the jobs which ran during last night, the success rate is 
decent (14 all-green runs vs. just 1 run where HA job was the sole CI 
failure).


I'm a bit reluctant still to say "let's make it voting" right now, but i 
think we should be heading that way gradually. If you see a failed HA CI 
job from now on, there's some chance it points out some real issue. 
Please try to go through the logs before overriding its vote and merging 
a patch with red HA CI. If the patch in question is not critical with 
regards to time, recheck is an option :)



Thanks

Jirka

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

Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

[Daniel Comnea]

My $0.2 cents:

I echo what Maish said with regards to functionality:
- integration with HEAT is a must from Day -1 (if there is anything like
this :) ) otherwise will be hard to gain operators traction. Look it as the
entry point for everyone trying to move from Neutron LB
- white/ black listing traffic based on source port/ network/IP
- multiple FIPs associated with 1 LB, the use case is: say i have 1 LB open
for port tcp 80 & udp 88 listening on 2 FIPs (even registered into a DNS)
and 2 different set of clients consuming this interfaces - frontend and
backend

Dani


Dani

On Thu, May 21, 2015 at 10:45 PM, Brandon Logan  wrote:

>  ​Right now its all or nothing as far as tcp ports go.  It currently does
> not have the functionality of white/black listinging traffic originating
> from a specific network.
>  --
> *From:* Maish Saidel-Keesing 
> *Sent:* Thursday, May 21, 2015 7:45 AM
> *To:* openstack-dev@lists.openstack.org
>
> *Subject:* Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship
> between Octavia and Barbican and Octavia 1.0 questions
>
>  Thanks Brandon
>
> On 05/20/15 22:58, Brandon Logan wrote:
>
> ​Just to add a few things,
>
> Barbican is not yet implemented in Octavia, though the code is there, we
> just need to spend a few hours hooking it all up and testing it out.
>
>
>  Also, the security groups are used by octavia right now so that only the
> ports on the listener are accessible.  Basically if a loadbalancer has
> listeners on ports 80 and 443, the vip ports will only allow traffic on
> those ports.  It shouldn't allow other traffic.
>
> That is great to hear. I assume that if we are using security groups we
> will also be able to define rules regarding which networks the listeners
> are allowed to accept traffic from?
>
> Is that assumption correct?
>
>
>  Thanks,
>
> Brandon
>  --
> *From:* Doug Wiegley 
> 
> *Sent:* Thursday, May 21, 2015 12:49 AM
> *To:* maishsk+openst...@maishsk.com; OpenStack Development Mailing List
> (not for usage questions); Maish Saidel-Keesing
> *Subject:* Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship
> between Octavia and Barbican and Octavia 1.0 questions
>
>  Hi Maish,
>
>  Thanks for the feedback, some answers below.  Please also be aware of
> the lbaas use cases session tomorrow at 9am (yuck, I know),
> https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases
>
>
>  On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing 
> wrote:
>
>  Hello all,
>
> Going over today's presentation "Load Balancing as a Service, Kilo and
> Beyond"[1] (great presentation!!) - there are a few questions I have
> regarding the future release:
>
> For Octavia 1.0:
>
> 1. Can someone explain to me how the flow would work for spinning up a a
> new Amphora with regards to interaction between Neutron, LBaaS and Barbican?
> Same question as well regarding how the standby is created and its
> relationship with Barbican.
>
>
>  The lbaas API runs inside neutron-server.  The general flow is:
>
>  - User interacts with neutron CLI/API or horizon (in liberty), and
> creates an LB.
> - Lbaas plugin in neutron creates logical models, fetches cert data from
> barbican, and calls the backend lbaas driver.
> - The backend driver does what it needs to to instantiate the LB. Today
> this is a synchronous call that waits for the nova boot, but by Liberty, it
> will likely be an async call to the octavia controller to finish the job.
>
>  Once Octavia has control, it is doing:
>
>  - Get REST calls for objects,
> - Talk to nova, spin up an amphora image,
> - Talk to neutron, plumb in the networks,
> - Send the amphora its config.
>
>
> 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is
> released or only further down the line?
> If not what would you suggest be the way to orchestrate LBaaS until this
> is ready?
>
>
>  We need to talk to the Heat folks and coordinate this, which we are
> planning to do soon.
>
>
> 3. Is there some kind of hook into Security groups also planned for the
> Amphora to also protect the Load Balancer?
>
>
>  Not at present, but I recorded this in the feature list on the etherpad
> above.
>
>
> I think that based on the answers to these questions above - additional
> questions will follow.
>
> Thanks
>
> [1] https://www.youtube.com/watch?v=-eAKur8lErU
> --
> Best Regards,
> Maish Saidel-Keesing
>  __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Best Regards,
> Maish Saidel-Keesing
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.

Re: [openstack-dev] [nova] Does Nova has a command line to restart an instance?

[Lily.Sing]

Hi all,

Thank you for your kindly reply. I forgot to check 'nova' command line, and
just tried 'openstack server'. It works for me.

Best regards,
Lily Xing(邢莉莉)

On Fri, May 22, 2015 at 1:22 PM, Chet Burgess  wrote:

> If you add the following option to your nova.conf file then when
> nova-compute restarts (at boot or simple on a restart) it will check the
> instances in the DB and attempt to start any instances that are marked as
> running in the DB but not running on the hypervisor.
>
> resume_guests_state_on_host_boot=True
>
> > On May 21, 2015, at 21:16, Lily.Sing  wrote:
> >
> > Hi experts,
> >
> > I setup an OpenStack multinode environment without Horizon installed.
> After host rebooting, the instances are in 'shutoff' status. I hope to
> re-use these instances, but seems there is no command line for this. Any
> suggestion?
> >
> > Thanks.
> >
> > Best regards,
> > Lily Xing(邢莉莉)
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev