date:20150324

and FWIW, please refer to
https://wiki.openstack.org/wiki/LiveMigrationWorkflows(maybe a little
outdated), anyway, hope it will make sense to you.

2015-03-24 16:06 GMT+08:00 Fic, Bartosz bartosz@intel.com:
 Hi guys,

 I would like to get to know about current live migration approach in nova.

 Maybe some of you could introduce me into basic live migration flow between
 files/services ?



 Regards,

 Bartosz


 __
 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!
---
Lingxian Kong

__
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 Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Thierry Carrez

Walter A. Boring IV wrote:
 Thanks Mike for all of your efforts on this,

+1

I think Mike checked all the possible boxes to give fair warning to
driver owners.

It's hard to say no in the name of quality. It's so much easier to
just say yes and avoid all the hatemail and the pressure.

Mike did the right thing, he did it the right way, and he needs all the
support the rest of our community can give him.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [nova] Revert objects: introduce numa topology limits objects

2015-03-24 Thread Nikola Đipanov

On 03/23/2015 02:06 PM, Dan Smith wrote:
 I am really sorry it got in as I have -1ed it several times for the same
 reason (I _really_ hate using the -2 hammer - we're all adults here
 after all).
 
 I guess that I should take some blame as a reviewer on that patch, but
 only after this mail do I read some of your comments as fundamentally
 opposed. The one that really articulates it wasn't a new vote so it
 stood out even less. IMHO, -2 is precisely for This shouldn't land as
 it is so would have been completely appropriate for this situation.
 It's a meaningful signal and has nothing to do with the age of the
 participants.
 
 My reasoning for it is quite simple and is outlined in the revert patch
 commit message:

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

 The reason for bringing this up on the email thread is that as a result
 we need to downgrade the RPC that has technically been released (k-3).

 Let me know what you think.
 
 I don't think we should revert it. Doing so will be quite messy. I think
 we have a couple of options:
 
 1. Leave it as-is. Especially since we are able to synthesize the old
 call when necessary, it seems clear that we haven't lost any information
 here. We deal with it, roll forward and fix it in L.
 
 2. We add to the object, essentially deprecating the ratio fields that
 you feel are problematic, and pass the data that you really want. That
 way we have a small window of compatibility that we can drop after we
 snap kilo.
 
 #1 requires no work now, but more work later; #2 requires quite a bit of
 work now, which might be scary, but makes life easier in the long run.
 
 Given where we are, and since I don't really see this as a
 sky-is-falling sort of thing, I think I'd err on the side of caution and
 go with #1. A flat-out revert either requires us to ban an RPC version
 (something we've never done, AFAIK) or just flat out roll back time and
 pretend it never happened.
 

Thanks for taking a look.

Yes, agreed - it is probably better to focus on actual bugs that impact
customers at this point.

I will abandon the reverts, and work on proposing the fix-up for L.

Cheers,
Nikola


__
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] EC2 API Sub team weekly meeting

2015-03-24 Thread M Ranga Swami Reddy

We'll have the weekly EC2 API sub team meeting [1] at 1400UTC in
#openstack-meeting today. We'll likely spend the majority of the time
going over current status along with critical bugs, as well as
covering BPs.

Please feel free to add other items in the  agenda [2] section.

Thanks!
Swami

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

[2] https://wiki.openstack.org/wiki/Meetings/EC2API#Agenda
__
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.config][kolla] modular backends for oslo.cfg

2015-03-24 Thread Flavio Percoco


On 19/03/15 13:31 +0100, Chmouel Boudjnah wrote:

Hello,

While on a long oversea flight with Sebastien Han we were talking how he had
implemented ceph-docker with central configuration over etcd. We quickly came
up to the conclusion that if we wanted to have that in Kolla it would be neat
if it was done straight from oslo.config so that would quickly override the
default keys in a central point.

There is multiple advantage to use that method not just for containers but as
well to avoid issues when orchestrating an openstack deployment.

I have heard arguments that this should be the job of an ansible/puppet/chef
tool and while I completely agree I just don't think it has to write to files
the tool would just write to the etcd database.

I have quickly came up with a quick and dirty POC on oslo.cfg here :

https://github.com/chmouel/oslo.config/commit/
01ee54dd5219b1434eaac422055b58e77694d89f

and the demo :

https://gist.github.com/chmouel/05fb715f96344161268c

What others thinks about it ?


IIRC, we had a talk about this in the past but it didn't go anywhere.
I personally like the idea and I believe it'd be useful for other
deployments too.



I believe if we wanted to do that we would have to add a stevesdor based
modular backend support directly to oslo.cfg first and have an etcd backend
implemented.


+1

This however won't remove the need of a config file. For instance,
plugins like etcd's will need the host/port options to be set
somewhere - or passed as a cli parameter.

Flavio


Chmouel

PS: I am using etcd here cause it's easy and fancy but this could be any
backends like a DB/NoSQL/Swift or whatever if we wanted



__
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



--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Murano] Murano agent development

2015-03-24 Thread Serg Melikyan

Hi Filip,

Sure, murano-agent is just a python application, you can easily run
this application locally (even in IDE like Pycharm with attached
debugger). To send execution plan to the agent you need to publish
execution plan to specified queue, results also will be published to
the queue.

murano-agent require configuration file for executing, you can build
sample configuration file using following instruction: tox -e
genconfig

Please, take a look at example murano-agent configuration file that
can be used to run it locally:

[DEFAULT]
# set location where obtained execution plans will be stored
storage = /tmp/murano/plans
debug = true
verbose = true

# credentials for rabbitmq
[rabbitmq]
host = localhost
port = 5672
login = guest
password = guest
virtual_host = /

# with this routing key execution plans results will be published
result_routing_key = None
# to this exchange execution plans results will be published
result_exchange = None
# from this queue agent will take exection plans
input_queue = None

On Tue, Mar 24, 2015 at 11:59 AM, Filip Blaha filip.bl...@hp.com wrote:
 Hello

 I would like to test and debug some new features of murano agent like chef
 recipes.

 I would like to know how to develop murano agent? How to test and debug new
 changes in agent code? Creating new image with every change and and test
 deployment on devstack is time-consuming and not very comfortable. Is there
 any shortcut for this development cycle?

 Thanks
 Filip

 __
 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



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

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

Re: [openstack-dev] [nova] Updating 'scheduled_at' field of nova instances in the database.

2015-03-24 Thread Deepthi Dharwar

On 03/24/2015 12:09 PM, Deepak Shetty wrote:
 
 
 On Tue, Mar 24, 2015 at 11:57 AM, Deepak Shetty dpkshe...@gmail.com
 mailto:dpkshe...@gmail.com wrote:
 
 
 
 On Tue, Mar 24, 2015 at 10:58 AM, Deepthi Dharwar
 deep...@linux.vnet.ibm.com mailto:deep...@linux.vnet.ibm.com wrote:
 
 On 03/23/2015 09:00 PM, Jay Pipes wrote:
  On Mon, Mar 23, 2015 at 11:18:28AM +0530, Deepthi Dharwar wrote:
  All the VM information is stored in the instances table.
  This includes all the time related field like scheduled_at, 
 launched_at etc.
 
  After upgrading to Juno, I have noticed that my 'scheduled_at' 
 field
  is not getting reflected at all in the database. I do see my VMs
  being spawned and running just fine. However, the 'launched_at' 
 time
  does get reflected rightly.
 
 
  MariaDB [nova] select created_at, deleted_at, host,scheduled_at, 
 launched_at from instances;
  
 +-+-+---+--+-+
  | created_at  | deleted_at  | host 
  | scheduled_at | launched_at |
  
 +-+-+---+--+-+
  | 2015-03-09 20:00:41 | 2015-03-10 17:12:11 | localhost
  | NULL | 2015-03-09 20:01:30 |
  | 2015-03-11 05:53:13 | NULL| localhost
   | NULL | 2015-03-18 19:48:12 |
 
 
  Can anyone let me know if this is a genuine issue or have there 
 been
  a recent change in regard to updating this field ?
 
  I am basically trying to find as to how long a particular VM is 
 running on a given host.
  I was using the current time - scheduled time for the same.
  Is there a better way to get this value ?
 
  Use current_time - launched_at.
 
 'launched_at' will give me the time a particular VM came into being.
 In a scenario where the VM was launched on host H1, later
 migrated on to
 a different host H2, 'launched_at' will not give the time the VM
 has been running on host H2, where as 'scheduled_at' would have
 addressed this issue or will it ?
 
 
 Per the code , patch @ https://review.openstack.org/#/c/143725/2
 removed scheduled_at
 since the function was no longer used. Googling i couldn't find more
 info on the history behind
 why these 2 fields were there to begin with.

IMHO launched_at = When the VM was first instantiated
 scheduled_at = Field updated whenever scheduler was invoked be
 it launching or migration.

 
 I am _not_ nova expert, but iiuc, a VM is scheduled
 once and changing the host as part of migration isn't scheduling,
 but i could be wrong too.
 
 Since your requirement is to find the time a VM lived on a host, as
 long as launched_at is updated
 post migration, it should suffice i feel ?

Yes, that's right.

 
 
 FWIW, In nova/compute/manager.py line 4036 is where migration ends and
 line 4042 is where
 the launched_at is updated, post migration.
 

It is really helpful to know that launched_at is indeed being updated.

 HTH
 
Thanks for all the digging in and for your time.

Regards,
Deepthi

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


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

Re: [openstack-dev] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

2015-03-24 Thread Salvatore Orlando

On 23 March 2015 at 14:49, Mathieu Rohon mathieu.ro...@gmail.com wrote:

 Hi romil,

 I think the main purpose of this DB field is to maintain the compatibility
 in dataplane between OVS and LinuxBridge which, by default, don't use the
 same UDP port for VXLAN.

It might be useful for a cloud admin which wants to run some nodes with LB
 and some others with OVS.


 I feel like your patch proposal will enable this scenario if the
 tunnel_update() RPC message gets updated with the UDP port too.


I have scanned a bit the ML2 code - to find out why we're storing
configuration info into the server side database.
It seems the tunnel_sync RPC callback it actually acts as a relay for
tunnel synchronisation messages from agents.
An agent notifies its tunnel information, these are stored into the server,
and then the server propagates updated information about tunnels to all
agents.
By storing the information in the DB we have a sort of guarantee against
lost messages, as the whole tunnel info would be relayed again the next
time an update comes up. So every agent will eventually receive the lost
message (where eventually means at some point before the end of the
universe and has nothing to do with eventual consistency).

While there might be questions about this approach, I don't think we have
time and energy to look at it before the end of the release cycle. In my
opinion if Romil's patch actually enable the scenario described by Mathieu
then it might make sense to change the RPC interface to allow this.
Otherwise, I don't think there's any urgency for squashing this change in
Kilo.

Salvatore


 Mathieu

 On Mon, Mar 23, 2015 at 11:40 AM, Romil Gupta romilgupt...@gmail.com
 wrote:

 Hello everyone,

 There is regarding the following bug:
 https://bugs.launchpad.net/neutron/+bug/1373359

 May I know what is the significance of having the '*udp_port'* field in
 the  *'ml2_vxlan_endpoints*' table in Neutron DB, Do we have any plans
 in future that we could use this field for synchronization or any other
 purpose instead of simply keeping it in the DB.

 The following patchset will fix the bug mentioned above,
 https://review.openstack.org/#/c/153891/

 But the question still remains the same. Do we need to keep this field or
 we need to remove it?

 --
 *Regards,*

 *Romil *

 __
 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] [Murano] Murano agent development

2015-03-24 Thread Stan Lagun

One trick that can be done to simplify agent development is to

a) configure it to listen to some specific queue and run it locally or on
VM (you can even run it from IDE under debugger) so that you can edit its
code in place
b) using code from agent.py write sample application that will send
execution plan to you agent

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

sla...@mirantis.com

On Tue, Mar 24, 2015 at 1:03 PM, Serg Melikyan smelik...@mirantis.com
wrote:

 Hi Filip,

 Sure, murano-agent is just a python application, you can easily run
 this application locally (even in IDE like Pycharm with attached
 debugger). To send execution plan to the agent you need to publish
 execution plan to specified queue, results also will be published to
 the queue.

 murano-agent require configuration file for executing, you can build
 sample configuration file using following instruction: tox -e
 genconfig

 Please, take a look at example murano-agent configuration file that
 can be used to run it locally:

 [DEFAULT]
 # set location where obtained execution plans will be stored
 storage = /tmp/murano/plans
 debug = true
 verbose = true

 # credentials for rabbitmq
 [rabbitmq]
 host = localhost
 port = 5672
 login = guest
 password = guest
 virtual_host = /

 # with this routing key execution plans results will be published
 result_routing_key = None
 # to this exchange execution plans results will be published
 result_exchange = None
 # from this queue agent will take exection plans
 input_queue = None

 On Tue, Mar 24, 2015 at 11:59 AM, Filip Blaha filip.bl...@hp.com wrote:
  Hello
 
  I would like to test and debug some new features of murano agent like
 chef
  recipes.
 
  I would like to know how to develop murano agent? How to test and debug
 new
  changes in agent code? Creating new image with every change and and test
  deployment on devstack is time-consuming and not very comfortable. Is
 there
  any shortcut for this development cycle?
 
  Thanks
  Filip
 
 
 __
  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



 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

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

__
OpenStack 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] live migration flow

correct the URL: https://wiki.openstack.org/wiki/LiveMigrationWorkflows

2015-03-24 19:38 GMT+08:00 Lingxian Kong anlin.k...@gmail.com:
 and FWIW, please refer to
 https://wiki.openstack.org/wiki/LiveMigrationWorkflows(maybe a little
 outdated), anyway, hope it will make sense to you.

 2015-03-24 16:06 GMT+08:00 Fic, Bartosz bartosz@intel.com:
 Hi guys,

 I would like to get to know about current live migration approach in nova.

 Maybe some of you could introduce me into basic live migration flow between
 files/services ?



 Regards,

 Bartosz


 __
 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!
 ---
 Lingxian Kong



-- 
Regards!
---
Lingxian Kong

__
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] [Ceilometer] Meters vs. Metrics

2015-03-24 Thread Zhai, Edwin


All,
I observed various meters and metrics with almost same meaning in telemetry 
part of admin-guild-cloud.


Just curious about the minor difference. If they are interchangeable, we can 
pick up one for confusion.




Best Rgds,
Edwin

__
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] live migration flow

IMHO, code talks everything :)

2015-03-24 16:06 GMT+08:00 Fic, Bartosz bartosz@intel.com:
 Hi guys,

 I would like to get to know about current live migration approach in nova.

 Maybe some of you could introduce me into basic live migration flow between
 files/services ?



 Regards,

 Bartosz


 __
 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!
---
Lingxian Kong

__
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.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Flavio Percoco


On 23/03/15 09:24 -0400, Doug Hellmann wrote:

Excerpts from Li Ma's message of 2015-03-23 18:23:39 +0800:

Hi all,

During previous threads discussing about zeromq driver, a subgroup may
be necessary to exchange knowledge and improve efficiency of
communication and development. In this subgroup, we can schedule a
given topic or just discuss some re-factoring stuff or bugs in irc
room at a fixed time.

Actually I'm not sure whether it is suitable to call it a 'subgroup'.
Besides, if it is possible, we need to figure out the suitable meeting
time and irc channel. Please give advice.


The goal we set at the Kilo summit was to have a group of people
interested in zmq start contributing to the driver, and I had hoped to
the library overall. How do we feel that is going?

One way to create a separate group to manage the zmq driver is to move
it to a separate repository. Is the internal API for messaging drivers
stable enough to do that?


At this point, I believe it is stable enough for having external
drivers. If the ZMQ team takes the first step here, it'd be an
unvaluable opportunity to see how this works and prepare the field for
future drivers.

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Deepak Shetty

On Tue, Mar 24, 2015 at 2:51 AM, Walter A. Boring IV walter.bor...@hp.com
wrote:

 On 03/23/2015 01:50 PM, Mike Perez wrote:

 On 12:59 Mon 23 Mar , Stefano Maffulli wrote:

 On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:

 We've been talking about CI's for a year. We started talking about CI
 deadlines
 in August. If you post a driver for Kilo, it was communicated that
 you're
 required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
 should've been known by your engineers regardless of when you submitted
 your
 driver.

 Let's work to fix the CI bits for Liberty and beyond. I have the feeling
 that despite your best effort to communicate deadlines, some quite
 visible failure has happened.

 You've been clear about Cinder's deadlines, I've been trying to add them
 also to the weekly newsletter, too.

 To the people whose drivers don't have their CI completed in time: what
 do you suggest should change so that you won't miss the deadlines in the
 future? How should the processes and tool be different so you'll be
 successful with your OpenStack-based products?

 Just to be clear, here's all the communication attempts made to vendors:

 1) Talks during the design summit and the meetup on Friday at the summit.

 2) Discussions at the Cinder midcycle meetups in Fort Collins and Austin.

 4) Individual emails to driver maintainers. This includes anyone else who
 has
 worked on the driver file according to the git logs.

 5) Reminders on the mailing list.

 6) Reminders on IRC and Cinder IRC meetings every week.

 7) If you submitted a new driver in Kilo, you had the annoying reminder
 from
 reviewers that your driver needs to have a CI by Kilo.

 And lastly I have made phone calls to companies that have shown zero
 responses
 to my emails or giving me updates. This is very difficult with larger
 companies because you're redirected from one person to another of who
 their
 OpenStack person is.  I've left reminders on given voice mail
 extensions.

 I've talked to folks at the OpenStack foundation to get feedback on my
 communication, and was told this was good, and even better than previous
 communication to controversial changes.

 I expected nevertheless people to be angry with me and blame me
 regardless of
 my attempts to help people be successful and move the community forward.

  I completely agree here Mike.   The Cinder cores, PTL, and the rest of
 the
 community have been talking about getting CI as a requirement for quite
 some time now.
 It's really not the fault of the Cinder PTL, or core members, that your
 driver got pulled from the Kilo
 release, because you had issues getting your CI up and stable in the
 required time frame.
 Mike made every possible attempt to let folks know, up front, that the
 deadline was going to happen.

 Getting CI in place is critical for the stability of Cinder in general.
  We have already benefited from
 having 3rd Party CI in place.  It wasn't but a few weeks ago that a change
 that was submitted actually
 broke the HP drivers.   The CI we had in place discovered it, and brought
 it to the surface.   Without
 having that CI in place for our drivers, we would be in a bad spot now.


+1, we (GlusterFS) too discovered issues with live snapshot (being one of
the very few that uses it in cinder)
tests failing as part of CI and we fixed it [1]

[1]: https://review.openstack.org/#/c/156940/

thanx,
deepak
__
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] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

On 18:20 Mon 23 Mar , Diem Tran wrote:
 Hello Cinder team,
 
 Oracle ZFSSA CI has been reporting since March 20th. Below is a link
 to the list of results the CI already posted:
 
 https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z
 
 Our CI system will be running and reporting results from now on,
 hence I kindly request that you accept our CI results and consider
 re-integrating our drivers back in Kilo RC.
 
 If there is any concern, please let us know.

Diem,

I appreciate your team getting back to us on the CI. It appears your CI is
running 247 tests, when it should be running 304. Please verify you're running
tempest as followed in the instructions here:

https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F

Once this issue is resolved, I'll continue to monitor the stability, and based
on that make a decision for readding the driver.

-- 
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] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Alessandro Pilotti

I also absolutely agree that Mike did a great job on the communication
with the driver maintainers and a lot more, especially in the hectic days
around the K-3 deadline.

Removing any driver lacking CI testing was just the right thing to do, even if
this affected our SMB3 driver. Hopefully this is just temporary as the related
CI is currently under test as well (whose delays are totally unrelated), so I
dont see it as a particularly dramatic decision. It also aligns well with the
policies applied it other major OpenStack projects like Nova or Neutron.

I'd be even in favor of a driver decomposition approach as Neutron did, but
that's another topic.

So, thanks again for all your great work and help!

Alessandro


 On 24 Mar 2015, at 16:41, Joshua Harlow harlo...@outlook.com wrote:
 
 +10 to mike; I have no doubt this is an uneasy and tough task.
 
 Thanks mike for pushing this through; given all the challenges and hard work 
 (and likely not fun work) that had to be done.
 
 I salute u! :)
 
 -Josh
 
 Duncan Thomas wrote:
 On 23 March 2015 at 22:50, Mike Perez thin...@gmail.com
 mailto:thin...@gmail.com wrote:
 
 
I've talked to folks at the OpenStack foundation to get feedback on my
communication, and was told this was good, and even better than previous
communication to controversial changes.
 
I expected nevertheless people to be angry with me and blame me
regardless of
my attempts to help people be successful and move the community forward.
 
 
 As somebody who has previously attempted to drive 3rd party CI in Cinder
 forward and completely burnt out on the process, I have to applaud
 Mike's efforts. We needed a line in the sand to force the issue, or we
 were never going to get to 100% coverage of drivers, which was what we
 desperately needed.
 
 For those who've have issues getting CI to be stable, this is a genuine
 reflection of the stability of Openstack in general, but it is not
 something we're going to be able to make progress on without CI systems
 exposing problems. That's the entire point of the 3rd party CI program -
 we knew there were bugs, stability issues and drivers that just plain
 didn't work, but we couldn't  do much about it without being able to
 test changes.
 
 Thanks to Mike for the finally push on this, and to all of the various
 people in both cinder and infra who've been very active in helping
 people get their CI running, sometimes in very trying circumstances.
 
 --
 Duncan Thomas
 
 __
 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] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Kyle Mestery

On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann d...@doughellmann.com
wrote:

 Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400:
 
  Echoing both Thierry and John.  I support Mike’s decision to enforce the
 requirement. Maintaining drivers in the tree comes with responsibilities to
 the community and 3rd party CI is one of the them.  Mike enforcing this
 requirement was the right action even if a hard one to take.
 
  mark

 Indeed. The deadlines were communicated clearly, and frequently.
 Making phone calls to reach out to contributors for issues like
 this is exceptional.

 +1000. Enabling contributors is great, but CI systems are an important
part of that enablement. I appreciate what Mike has done to drive Cinder
towards a quality level for all contributors here. It's a hard stance to
take, but saying No can sometimes be the right decision.

Thanks,
Kyle



 Doug

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

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

Re: [openstack-dev] [neutron] FF and our march towards the RC

2015-03-24 Thread Itsuro ODA

Kyle and cores,

There are some fixes [1] I want to get merged in kilo-rc1.
(These fixes stay for a long time on gerrit because 
 they have not gained core's review much.)

I'd like to set milestone to kilo-rc1 for these fixes but
I can't set milestone field of launchpad.

I wish cores are interested in these fix and support to
get merged.

[1] 
* https://review.openstack.org/147032/
  (see also: 
http://lists.openstack.org/pipermail/openstack-dev/2015-March/059466.html )
* https://review.openstack.org/161947/
* https://review.openstack.org/150284/
* https://review.openstack.org/149458/

Thanks.
Itsuro Oda

On Tue, 24 Mar 2015 12:12:58 -0500
Kyle Mestery mest...@mestery.com wrote:

 Folks:
 
 I've gone through the BPs granted an FFE and I have our RC-1 setup now [1].
 Please note that the BPs in there all need to merge by the dates specified
 in the BP in Launchpad. Most are by next Tuesday, March 31. But the LBaaS
 drivers need to go in by Friday. If these BPs don't land by then, they'll
 be out of Kilo. We need a solid 2 weeks to work on bugs that crop up as
 we're testing Neutron Kilo.
 
 I'll be working the bug list next. If you feel a bug should be a release
 candidate, target it to RC1 for now.
 
 Core Reviewers: Please be cautious about merging code at this point. When
 in doubt, find me in #openstack-neutron.
 
 Thanks!
 Kyle
 
 [1] https://launchpad.net/neutron/+milestone/kilo-rc1

-- 
Itsuro ODA o...@valinux.co.jp


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

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

2015-03-24 Thread Ian Wells

On 24 March 2015 at 11:45, Armando M. arma...@gmail.com wrote:

 This may be besides the point, but I really clash with the idea that we
 provide a reference implementation on something we don't have CI for...


Aside from the unit testing, it is going to get a test for the case we can
test - when using the standard config networking that Tempest runs with,
does it return the right answer?  That's pretty much the level of
commitment that the entire test suite gives.

Beyond that, it is about as well tested by the upstream testing as the ML2
plugin (which, in the main tests, is tested in one config only) and more
well tested than the LB driver (I don't eisn't touched by the system tests
but is still in-tree).  I'm not out to make the test coverage any worse,
and I apologise that we can't test this when it's returning a positive
result, but the system tests do have limitations in this regard.

That said, I'd love to put a positive test in the system tests if only we
can work out how to do one - suggestions welcome...
-- 
Ian.
__
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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

Mike Perez on March 24, 2015 16:39 wrote:
On 15:13 Tue 24 Mar , Stefano Maffulli wrote:
 On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote:
  *Somehow queueing requests in the IRC channel so that offline
  developers can easily find review requests when looking at channel
  logs
 
 Maybe we can hack an IRC bot so that it collects review requests and
 lists them on eavesdrop? Something like a user on irc writes:
 
 : please review https://URL because it's needed for GOODREASONS #review
 
 and on a web page like http://eavesdrop.openstack.org/ we add 'requests
 for reviews', maybe an rss feed.
 
 BTW, Thierry had a similar request a few weeks back for a system to
 quickly share 'good news' and create a stream of reasons for
 happyness :)

Python core has an issue summary sent to their list every week [1].

Could do something like this, but with review requests. Using similar filters
from the dashboard [2] like open review requests updated that week, what was
merged, what's close to being merged (has at least one +2) or has a lot of
support (x number of +1's).

Could be a bit much on the dev ML with every project, but maybe acceptable if
we continue to prefix the subject with [project] + filters.

[Rockyg] This actually sounds like a good idea, especially if the subject is 
identical except for the project filters.  That would make it easy to filter 
out even if you read the whole mailing list, but don't want to track the review 
lists.

--Rocky


[1] - https://mail.python.org/pipermail/python-dev/2015-March/138628.html
[2] - https://wiki.openstack.org/wiki/Cinder#Review_Links

-- 
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] [Neutron] Neutron extenstions

2015-03-24 Thread Christopher Yeoh


Hi Doug,
On Thu, 19 Mar 2015 10:01:54 -0600
Doug Wiegley doug...@parksidesoftware.com wrote:

 Hi Gary,
 
 First I’m seeing these, but I don’t see that they’re required on
 input, unless I’m mis-reading those reviews.  Additional of new
 output fields to a json object, or adding optional inputs, is not
 generally considered to be backwards incompatible behavior in an API.
 Does OpenStack have a stricter standard on that?

So speaking from a Nova (and more general) API point of view where
we're probably a bit longer along the extensions/microversioning path,
I think even with backwards compatibility it is still an issue. For
example, without some sort of co-operative and strong input validation
are you going to detect when someone sends a new parameter that is
simply mispelled and all the other extensions assume that someone will
look after it and return an appropriate rather than let it just through.

Over time we've found a few examples even in our api request samples
typos (which feeds into the docs) which are not detected just because
of this situation.

Chris

 
 Thanks,
 doug
 
 
  On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@vmware.com wrote:
  
  Hi,
  Changed the subject so that it may draw a little attention.
  There were 2 patches approved that kind of break the API (in my
  humble opinion): https://review.openstack.org/#/c/154921
  https://review.openstack.org/#/c/154921/ and
  https://review.openstack.org/#/c/158420
  https://review.openstack.org/#/c/158420/ In both of these two new
  fields were added to the base attributes – mtu and
  vlan_transparency Reverts for them are:
  https://review.openstack.org/165801
  https://review.openstack.org/165801 (mtu) and
  https://review.openstack.org/165776
  https://review.openstack.org/165776 (vlan transparency). In my
  opinion these should be added as separate extensions. Thanks Gary
  
  From: Gary Kotton gkot...@vmware.com mailto:gkot...@vmware.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  mailto:openstack-dev@lists.openstack.org Date: Thursday, March
  19, 2015 at 2:32 PM To: OpenStack List
  openstack-dev@lists.openstack.org
  mailto:openstack-dev@lists.openstack.org Subject: Re:
  [openstack-dev] [Neutron] VLAN transparency support
  
  Hi,
  This patch has the same addition too -
  https://review.openstack.org/#/c/154921
  https://review.openstack.org/#/c/154921/. We should also revert
  that one. Thanks Gary
  
  From: Gary Kotton gkot...@vmware.com mailto:gkot...@vmware.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  mailto:openstack-dev@lists.openstack.org Date: Thursday, March
  19, 2015 at 1:14 PM To: OpenStack List
  openstack-dev@lists.openstack.org
  mailto:openstack-dev@lists.openstack.org Subject:
  [openstack-dev] [Neutron] VLAN transparency support
  
  Hi,
  It appears that https://review.openstack.org/#/c/158420
  https://review.openstack.org/#/c/158420/ update the base
  attributes for the networks. Is there any reason why this was not
  added as a separate extension like all others. I do not think that
  this is the correct way to go and we should do this as all other
  extensions have been maintained. I have posted a revert
  (https://review.openstack.org/#/c/165776
  https://review.openstack.org/#/c/165776/) – please feel free to
  knack if it is invalid. Thanks Gary
  __
  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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

2015-03-24 Thread Stefano Maffulli

On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote:
 So, how do we get timely first core review of patches in areas of the
 world where Core presence in IRC is slim to none?

I think that most core reviewers use bouncers, so notifying them in the
channel would probably raise a notification in their clients when they
connect back. I understand the feeling though: as the sender of a
message over IRC, I have no good way to understand if the message was
delivered to the recipient as expected.

I'd start with advising to use the bouncer and ping the core reviewers
on channel with review requests. (more about this below)
 
 I can think of a few options but they don’t seem great:  
 
 ·A filter for dashboards that flags reviews with multiple +1s
 and no core along with a commitment of the Core team to perform a
 review within x number of days
 
This might work, modulo the 'committment' of core team which I think
cannot go above a best effort.

 ·A separate mailing list for project review requests

I'm skeptical about this being effective: just another source of
incoming email that needs to be filtered out (at which point a mailman
topic would have the same effect).

 ·Somehow queueing requests in the IRC channel so that offline
 developers can easily find review requests when looking at channel
 logs

Maybe we can hack an IRC bot so that it collects review requests and
lists them on eavesdrop? Something like a user on irc writes:

: please review https://URL because it's needed for GOODREASONS #review

and on a web page like http://eavesdrop.openstack.org/ we add 'requests
for reviews', maybe an rss feed.

BTW, Thierry had a similar request a few weeks back for a system to
quickly share 'good news' and create a stream of reasons for
happyness :)
 
 Solving this issue could help not just Third Party developers, but all
 of OpenStack and make the community more inviting to Asian and
 Australian (and maybe European and African) developers.

In general, make it more resilient and asynchronous, not just because of
timezones.

/stef


__
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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

On 15:13 Tue 24 Mar , Stefano Maffulli wrote:
 On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote:
  ·Somehow queueing requests in the IRC channel so that offline
  developers can easily find review requests when looking at channel
  logs
 
 Maybe we can hack an IRC bot so that it collects review requests and
 lists them on eavesdrop? Something like a user on irc writes:
 
 : please review https://URL because it's needed for GOODREASONS #review
 
 and on a web page like http://eavesdrop.openstack.org/ we add 'requests
 for reviews', maybe an rss feed.
 
 BTW, Thierry had a similar request a few weeks back for a system to
 quickly share 'good news' and create a stream of reasons for
 happyness :)

Python core has an issue summary sent to their list every week [1].

Could do something like this, but with review requests. Using similar filters
from the dashboard [2] like open review requests updated that week, what was
merged, what's close to being merged (has at least one +2) or has a lot of
support (x number of +1's).

Could be a bit much on the dev ML with every project, but maybe acceptable if
we continue to prefix the subject with [project] + filters.

[1] - https://mail.python.org/pipermail/python-dev/2015-March/138628.html
[2] - https://wiki.openstack.org/wiki/Cinder#Review_Links

-- 
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] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On 15:59 Tue 24 Mar , arkady_kanev...@dell.com wrote:
 Dell - Internal Use - Confidential
 The link from cinder page to Cinder review inbox
 (https://review.openstack.org/#/dashboard/) from
 https://wiki.openstack.org/wiki/Cinder#Resources is empty.
 
 Link to bugs does work.

I'm using the dashboard right now and it's working fine for me. Make sure
you're logged into Gerrit before visiting.

-- 
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] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Tim Hinrichs

Hi Bryan,

I wish we could claim Congress has most of the data from OpenStack APIs already 
available for policy, but that’s not the case today.

If it were me, I’d start with your use cases, figure out which services and API 
calls you’ll need to support those use cases, and then check if those APIs are 
already available in Congress.

Tim

On Mar 24, 2015, at 1:47 PM, Bryan Sullivan 
bls...@hotmail.commailto:bls...@hotmail.com wrote:

Thanks for clarifying, Tim (and Alex for the other response).

Since I have to understand the code anyway going to the drivers for current 
info is reasonable.

Can I derive from your statement One of Congress’s goals is to make any data 
available via an API call to policy-related that Congress already exposes (in 
Congress tables) most/all data available through OpenStack component APIs? That 
would save me digging through the OpenStack code as well.


From: thinri...@vmware.commailto:thinri...@vmware.com
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tue, 24 Mar 2015 19:57:26 +
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan,

Inline.

On Mar 24, 2015, at 12:13 PM, Bryan Sullivan 
bls...@hotmail.commailto:bls...@hotmail.com wrote:

Hi, I have a question about where to find the complete set of currently 
supported data drivers (with table/row details) for Congress. The info at 
http://congress.readthedocs.org/en/latest/cloudservices.html#drivershttps://urldefense.proofpoint.com/v2/url?u=http-3A__congress.readthedocs.org_en_latest_cloudservices.html-23driversd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7sm=7K6Tq1uqgCY-gmJMedkayeCZgjUEWp7QD_HaJg6pHmYs=rEUZxD7aLCxwILxm2ugsR4Qr-4JXCdZ_-9BWcvG5F_ke=
 seems to cover only Nova and Neutron.  I'm sure that I can pull this info from 
the source at 
https://github.com/stackforge/congress/tree/master/congress/datasourceshttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_congress_tree_master_congress_datasourcesd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7sm=7K6Tq1uqgCY-gmJMedkayeCZgjUEWp7QD_HaJg6pHmYs=XeNw_NiKGg3HrR5R6oVbN9EVV2RhB3CQ4waMWGvBAHMe=
 but I was looking for any documentation on the current state of that code's 
design. The existing blueprints (e.g. at 
https://github.com/stackforge/congress-specs)https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_congress-2Dspecs-29d=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7sm=7K6Tq1uqgCY-gmJMedkayeCZgjUEWp7QD_HaJg6pHmYs=AjqWychcmYYsMd9oOGytLq3rXOqzhJGLbUTi2OuX2_0e=
 do not go into this detail AFAICT.


I’d definitely just do a directory listing on the source code.  Syncing the 
docs is something we do before a major release.  Things are just changing too 
quickly to do anything else.

Also, since I'm looking into how the current supported Congress tables will 
support use cases of the OPNFV Copper project [1], it will be also helpful to 
know where I would look for the set of potential policy-related data items 
inside OpenStack docs/code for the various components. If I find a gap against 
a use case, I would want to be able to specify related patches (e.g. where data 
source driver extensions should get the additional data) so I need to know 
where the data comes from (and what's available) inside OpenStack.


One of Congress’s goals is to make any data available via an API call to 
policy-related.  So anything the API calls of OpenStack returns are reasonable 
candidates for writing policy over.

Tim

[1] 
https://wiki.opnfv.org/copper/use_caseshttps://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.opnfv.org_copper_use-5Fcasesd=AwMF-gc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7sm=lssF60z2CQNbUwpN7SMHds5C8d33H4qy6lYURJ57ifMs=SWYETWsuJ04nF3g_lUDlGGi7SlwgIHjobgh9d5zGLA4e=

Thanks for your help!
Bryan





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto: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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?



Jeremy Stanley on March 24, 2015 07:28 wrote:
On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote:
[...]
 I'm really not a fan of the Defcore effort. This should come as no
 surprise to anyone. I've been quite blunt about my disdain for the
 focus on identifying which API things are mandatory and which are
 optional, in order to say some vendor's product is OpenStack.
[...]

Understandable--and I'm certainly no fan of bureaucracy and
politicking--just pointing out that in the carrots-and-sticks bin we
have trademarks as a potential carrot to encourage people running
OpenStack commercially to further the goals of our community. If
there is broad community support for the idea that standard
OpenStack APIs should not be arbitrarily extended downstream because
it hurts interoperability, then this might be one way to improve the
situation. If there are other means to achieve this then they too
should be considered, obviously.

[Rockyg] Tl;dr.  Propose it to DefCore.  They might agree.  But they might have 
action items for developers to make it actionable on DefCore's part.

Hey, it sounds like a reasonable request to me, and it's a large operator 
making the request for DefCore to recognize that extensions break 
interoperability.  Plus, Defcore specifically states that vendor specific code 
within OpenStack is not considered for inclusion in the Defcore 
capabilities/test/designated code sets.

So then the questions become: 

* Are there any currently included capabilities that assume extensions work?
* Are there any likely candidates for future Defcore sets that assume 
extensions work?
* Will extensions be deprecated before capabilities requiring extensions are in 
the candidate pool?
* Once extensions are deprecated, or it is known that nothing in Defcore sets 
include the ability to use extensions, are there tests which will validate that 
extensions are not part of the cloud under test?

Something to think about, and if you are serious about limiting the negative 
effects of extensions, it is certainly worth proposing their elimination and/or 
restrictions on them to Defcore.

And an FYI, APIs and tests are not chosen by DefCore because they are 
meaningful, but because they are measurable.  DefCore uses User Surveys (and 
who knows what else) to determine adoption rates of OpenStack capabilities 
that are then converted to APIs and tests, etc.  If you have a implementable 
ideas on how better to measure individual clouds/cloud products against the 
user communities' utilization, they'd love to hear from you.  No, really. 
DefCore wants to hear of better ways to ensure that clouds with the OpenStack 
trademark mean that user implementations on those clouds are portable across 
compliant vendors within the scope of what those vendors advertise. 

--rocky

-- 
Jeremy Stanley

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

__
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] Quota management and enforcement across projects

2015-03-24 Thread Dimitri Mazmanov

Hi,
Interesting  thread. I’ve just started looking at Boson myself to manage quotas 
across multiple regions. I think one of the cases when having quota management 
as a separate service is justified, is a multi-region case [1].

1) Some deployments can share Keystone, so there’s a need to synchronise 
resource usage across multiple OpenStacks and enforce quota in a distributed 
manner. Architecturally this will mean that there will be one Boson instance 
with the “quota management” and “admin” roles exposing REST API endpoint and 
talking REST to other client specific Boson instances. This use case can be an 
example of why it can be reasonable to have a separate service for managing 
quotas, reservations, usages.

2) As I understand it, the intention of Boson is to synchronise usage, not own 
this information. The “Usage synchronisation” paragraph in the wiki [3] 
describes one possible approach:
“…Boson will keep freshness information on the usage data; should it determine 
that the usage information it has is not fresh enough, it will reject 
reservation creation requests with a special response code, which tells the 
service to send fresh usage information for certain resources along with 
resending the reservation creation requests”.
Further, the service can reject reservation creation requests in case of 
communication failure, tracker unavailability, etc.

3) Have you looked at Blazar [3] as a possible reservation mechanism instead of 
implementing a new reservation interface in Boson? Does it at all make sense to 
use it in the context of quota management?

Regards,
Dimitri

[1] http://dc636.4shared.com/download/Z6O_jJSGba/multiregion_arch.png?lgfp=3000
[2]https://wiki.openstack.org/wiki/Boson#Usage_Synchronization
[3] https://wiki.openstack.org/wiki/Blazar

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday 15 January 2015 02:22
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Quota management and enforcement across projects

I'm resurrecting this thread to provide an update on this effort.

I have been looking at Boson [1] as a base for starting developing a service 
for managing quotas and reservations [2].
Boson's model would satisfy most of the requirements for this service, and 
implementing additional requirements, such as hierarchical multi-tenancy should 
be quite easy (at least from the high-level design perspective). In the rest of 
this post I'm going to refer to this service both as Boson and quota 
service.

Without going into too many technical details (which I am happy to discuss 
separately), the quota service will need to provide the 4 interfaces depicted 
in [3].
1) The admin interface has the main purpose of keeping track of the services 
which use boson, registering resources to track, and managing their lifecycle.
2) The quota mgmt interface does pretty much what the quota extension does 
for many openstack project - manage resource limits per project/users, 
configure quota classes, etc.
3) The reservation interface handles the request/commit/cancel process 
supported by many Openstack projects
4) the usage interface provides abstraction to access the resource usage 
tracker and feed information to it.

These interfaces are then implemented by the Boson object model, depicted in 
[4].
This object model is not very different from the one originally proposed for 
Boson [5]
The proposed object model simplifies a bit the original one, merging the 
reservation and request concepts, as well as doing without the 
SpecificResource concept (at least for the moment). However, the proposed 
object model adds the Quota class concept and introduces the possibility of 
having child-parent relationships between Resources and User Info. The former 
will allow for applying quota to resources which are scoped within a parent 
resource (e.g.: static routes per logical router), whereas the latter should 
enable the hierarchical multi-tenancy use case.

Keeping in mind the interfaces discussed in [3], the component diagram [6] can 
be devised. There is a distinct component for each interface - plus one 
component for DB management. Most of the interactions are, of course, with the 
DB manager. Component design should be done in a way that the various 
components are as independent as possible. There are some interactions among 
components, but they can likely be replaced with interactions with the DB 
manager component.

The Boson quota service therefore represents a centralized endpoint for 
managing quotas, tracking resource usage, and performing resource reservation.
Conceptually, this is all good; however, would it scale from an architectural 
perspective? The main problem with this approach

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

Excerpts from Li Ma's message of 2015-03-24 23:31:22 +0800:
 On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote:
  The goal we set at the Kilo summit was to have a group of people
  interested in zmq start contributing to the driver, and I had hoped to
  the library overall. How do we feel that is going?
 
 That sounds great. I hope so.
 
  One way to create a separate group to manage the zmq driver is to move
  it to a separate repository. Is the internal API for messaging drivers
  stable enough to do that?
 
 Actually I'm not intended to move it to a separate repository. I just
 want to make sure if it is possible to make a fixed online meeting for
 zmq driver.
 

OK, that's fine, too. I thought if the point was to get more reviews,
moving it to a separate repository with a different review team might
help.

Doug

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

Re: [openstack-dev] About Sahara EDP New Ideas for Liberty

2015-03-24 Thread Trevor McKay

Weiting, Andrew,

Agreed, great ideas!  As Andrew noted, we have discussed some of these
things before and it would be great to discuss them in Vancouver.

I think that a Sahara-side workflow manager is the right approach. Oozie
has a lot of capability for job coordination, but it won't work for all
of our cluster and job types.

Notes on Spark in particular -- when we implemented Spark EDP, we looked
at various implementations for a Spark job server.  One was to extend
Oozie, one was to use the Ooyala Spark job server, and one was to use
ssh around spark-submit.  We chose the last, notes are here:

https://etherpad.openstack.org/p/sahara_spark_edp

We could potentially revisit the Ooyala job server.  My impression at
the time was that for the functions we wanted, it was pretty heavy. But
if we are going to add job coordination as a general feature, it may be
appropriate. I believe in the Spark community it is the dominant
solution for job management, open source is here:

https://github.com/spark-jobserver/spark-jobserver

As part of the Spark investigation, I posted on this JIRA, too. This is
a JIRA for developing a REST api to the spark job server, which may be
enough for us to build our own coordination system:

https://issues.apache.org/jira/browse/SPARK-3644

Best,

Trevor

On Tue, 2015-03-24 at 01:55 +, Chen, Weiting wrote:
 Hi Andrew.
 
  
 
 Thanks for response. My reply in line.
 
  
 
 From: Andrew Lazarev [mailto:alaza...@mirantis.com] 
 Sent: Saturday, March 21, 2015 12:10 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] About Sahara EDP New Ideas for Liberty
 
  
 
 Hi Weiting,
 
  
 
 
 1. Add a schedule feature to run the jobs on time:
 
 
 This request comes from the customer, they usually run the job in a
 specific time every day. So it should be great if there
 
 
  is a scheduler to help arrange the regular job to run.
 
 
 Looks like a great feature. And should be quite easy to implement.
 Feel free to create spec for that.
 
 
 [Weiting] We are working on the spec and the bp has already been
 registered in
 https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs.
 
  
 
 
 2. A more complex workflow design in Sahara EDP:
 
 
 Current EDP only provide one job that is running on one cluster.
 
 
 Yes. And ability to run several jobs in one oozie workflow is
 discussed on every summit (e.g. 'coordinated jobs' at
 https://etherpad.openstack.org/p/kilo-summit-sahara-edp). But for now
 it was not a priority
 
 
  
 
 
 But in a real case, it should be more complex, they usually use
 multiple jobs to calculate the data and may use several different type
 clusters to process it..
 
 
 It means that workflow manager should be on Sahara side. Looks like a
 complicated feature. But we would be happy to help with designing and
 implementing it. Please file proposal for design session on ongoing
 summit. Are you going to Vancouver?
 
 
 [Weiting] I’m not sure I will be there because the plan is still not
 ready yet. We are also looking for some customer’s real case in big
 data area and see how they are using data processing in current
 environment. However, for any idea we can update later. 
 
  
 
 
 Another concern is about Spark, for Spark it cannot use Oozie to do
 this. So we need to create an abstract layer to help to implement this
 kind of scenarios.
 
 
 If workflow is on Sahara side it should work automatically for all
 engines.
 
 [Weiting] Yes, agree.
 
 
  
 
 
 Thanks,
 
 
 Andrew.
 
  
 
 
  
 
 
  
 
 On Sun, Mar 8, 2015 at 3:17 AM, Chen, Weiting weiting.c...@intel.com
 wrote:
 
 Hi all.
 
  
 
 We got several feedbacks about Sahara EDP’s future from some
 China customers.
 
 Here are some ideas we would like to share with you and need
 your input if we can implement them in Sahara(Liberty).
 
  
 
 1. Add a schedule feature to run the jobs on time:
 
 This request comes from the customer, they usually run the job
 in a specific time every day. So it should be great if there
 is a scheduler to help arrange the regular job to run.
 
  
 
 2. A more complex workflow design in Sahara EDP:
 
 Current EDP only provide one job that is running on one
 cluster. 
 
 But in a real case, it should be more complex, they usually
 use multiple jobs to calculate the data and may use several
 different type clusters to process it.
 
 For example: Raw Data - Job A(Cluster A) - Job B(Cluster B)
 - Job C(Cluster A) - Result
 
 Actually in my opinion, this kind of job could be easy to
 implement by using Oozie as a workflow engine. But for current
 EDP, it doesn’t implement this kind of complex case.
 
 Another concern is about Spark, for

[openstack-dev] [kolla] Announcing k3 release of Kolla

2015-03-24 Thread Steven Dake (stdake)

Hello,

The Kolla community is pleased to announce the release of Kilo #3 of the Kolla
project. It is available for immediate download from:
https://github.com/stackforge/kolla/archive/k3.tar.gz

This version removes Kubernetes entirely as a development environment. We
found we needed super-privileged containers to properly deploy OpenStack. As a
result we are now using docker-compose. The heat-community is in the process
of producing a resource for managing oocker-compose components. This should
permit the integration of Kolla with third party tools that use Heat for
deployment. Alternatively docker-compose can be used directly.

To get started, read the quickstart guide:
https://github.com/stackforge/kolla/blob/master/docs/developer-env.md

This version allows the starting of a full container on bare-metal deployment.
The tools/start script will deploy a working deployment of:

* mariadb

* rabbitmq

* keystone

* glance-api and glance-registry

* nova-api, nova-conductor, and nova-scheduler

* libvirt, nova-compute, nova-network

* heat-api and heat-engine

* Horizon

This version of Kolla uses OpenStack Legacy networking called nova-network.
Make sure to edit the /tools/genev and supply the correct device name (i.e.
eth1) for the interface used by nova-network's FLAT_INTERFACE. For more on Nova
networking, please refer to:
http://docs.openstack.org/juno/install-guide/install/yum/content/section_nova-networking.html

New Features

* A new implementation based upon super-privileged containers

* Docker-compose has replaced kubernetes as the deployment tool

* Documentation for starting a development environment

* Documentation for integrating with Kolla

*Improved parameterization of OpenStack configuation files.

Quickstart:

* Run tools/genenv.sh to generate your environment variables

* Source your credentials (openrc), which will be added kolla/ directory

* Install the openstack clients on your host

* Test out individual services:

* $ keystone user-list

Please give it a run today and provide your feeedback!

Regards,
- The Kolla 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

Re: [openstack-dev] [kolla] Announcing k3 release of Kolla

2015-03-24 Thread Mitsuhiro SHIGEMATSU

sdake, cool!

-- pshige
2015/03/25 0:29 Steven Dake (stdake) std...@cisco.com:

   Hello,

  The Kolla community is pleased to announce the release of Kilo #3 of the
 Kolla project.  It is available for immediate download from:
 https://github.com/stackforge/kolla/archive/k3.tar.gz

  This version removes Kubernetes entirely as a development environment.
 We found we needed super-privileged containers to properly deploy
 OpenStack.  As a result we are now using docker-compose.  The
 heat-community is in the process of producing a resource for managing
 oocker-compose components.  This should permit the integration of Kolla
 with third party tools that use Heat for deployment.  Alternatively
 docker-compose can be used directly.

  To get started, read the quickstart guide:
  https://github.com/stackforge/kolla/blob/master/docs/developer-env.md

  This version allows the starting of a full container on bare-metal
 deployment.  The tools/start script will deploy a working deployment of:

- mariadb


- rabbitmq


- keystone


- glance-api and glance-registry


- nova-api, nova-conductor, and nova-scheduler


- libvirt, nova-compute, nova-network


- heat-api and heat-engine


- Horizon


  This version of Kolla uses OpenStack Legacy networking called
 nova-network. Make sure to edit the /tools/genev and supply the correct
 device name (i.e. eth1) for the interface used by nova-network's
 FLAT_INTERFACE. For more on Nova networking, please refer to:
 http://docs.openstack.org/juno/install-guide/install/yum/content/section_nova-networking.html

  New Features

- A new implementation based upon super-privileged containers


- Docker-compose has replaced kubernetes as the deployment tool


- Documentation for starting a development environment


- Documentation for integrating with Kolla


-  Improved parameterization of OpenStack configuation files.


  Quickstart:

- Run tools/genenv.sh to generate your environment variables


- Source your credentials (openrc), which will be added kolla/
directory


- Install the openstack clients on your host


- Test out individual services:


- $ keystone user-list


  Please give it a run today and provide your feeedback!

  Regards,
 - The Kolla 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

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Joshua Harlow


+10 to mike; I have no doubt this is an uneasy and tough task.

Thanks mike for pushing this through; given all the challenges and hard 
work (and likely not fun work) that had to be done.


I salute u! :)

-Josh

Duncan Thomas wrote:

On 23 March 2015 at 22:50, Mike Perez thin...@gmail.com
mailto:thin...@gmail.com wrote:


I've talked to folks at the OpenStack foundation to get feedback on my
communication, and was told this was good, and even better than previous
communication to controversial changes.

I expected nevertheless people to be angry with me and blame me
regardless of
my attempts to help people be successful and move the community forward.


As somebody who has previously attempted to drive 3rd party CI in Cinder
forward and completely burnt out on the process, I have to applaud
Mike's efforts. We needed a line in the sand to force the issue, or we
were never going to get to 100% coverage of drivers, which was what we
desperately needed.

For those who've have issues getting CI to be stable, this is a genuine
reflection of the stability of Openstack in general, but it is not
something we're going to be able to make progress on without CI systems
exposing problems. That's the entire point of the 3rd party CI program -
we knew there were bugs, stability issues and drivers that just plain
didn't work, but we couldn't  do much about it without being able to
test changes.

Thanks to Mike for the finally push on this, and to all of the various
people in both cinder and infra who've been very active in helping
people get their CI running, sometimes in very trying circumstances.

--
Duncan Thomas

__
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] EC2 API Sub team weekly meeting

2015-03-24 Thread M Ranga Swami Reddy

As we got the conflict with meeting room, moved this meeting to
#openstack-meeting-3 room.
But, only Rushiagr joined the meeting and so could not discuss the
current status and other items and end the meeting.

 Minutes:
http://eavesdrop.openstack.org/meetings/ec2_api/2015/ec2_api.2015-03-24-14.08.html
 Minutes (text):
http://eavesdrop.openstack.org/meetings/ec2_api/2015/ec2_api.2015-03-24-14.08.txt
 Log:
http://eavesdrop.openstack.org/meetings/ec2_api/2015/ec2_api.2015-03-24-14.08.log.html

Thanks
Swami


On Tue, Mar 24, 2015 at 3:43 PM, M Ranga Swami Reddy
swamire...@gmail.com wrote:
 We'll have the weekly EC2 API sub team meeting [1] at 1400UTC in
 #openstack-meeting today. We'll likely spend the majority of the time going
 over current status along with critical bugs, as well as covering BPs.

 Please feel free to add other items in the  agenda [2] section.

 Thanks!
 Swami

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

 [2] https://wiki.openstack.org/wiki/Meetings/EC2API#Agenda




__
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] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-24 Thread Matt Riedemann




On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:

I see you point Van,

In the other hand, removing it, cleans up lot of conditional code parts
(moving parts at the other side),
and also the non-netns case is not tested by upstream CI, AFAIK, so it
could be broken anytime
and we would not notice it.



Miguel Ángel Ajo

On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:


I think there are valid reasons to not use namespaces:

  * Fewer moving parts == less can potentialy fail
  * Troubleshooting is easier due to less places to look / need no
familiarity with namespaces  tools
  * If I remember correctly setting up a namespace can get really
slow when you have a lot of them on a single machine



 IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, 
or sudo issues
 that have been corrected long ago, and all distros installing neutron are 
supporting netns at this

Well, you exactly made my point:
There is lots that can and will go wrong with more moving parts.
That they are fixed at the moment does not mean that there will not be
a new bug in the future…

Cheers,
Robert van Leeuwen
___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
mailto:openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




__
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



FWIW we were doing CI without namespaces before Kilo simply due to RHEL 
6.5 not having the support w/o a kernel patch.


Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that 
has namespace support so it's no longer an issue for us.


--

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] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Ben Nemec

On 03/24/2015 10:31 AM, Li Ma wrote:
 On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote:
 The goal we set at the Kilo summit was to have a group of people
 interested in zmq start contributing to the driver, and I had hoped to
 the library overall. How do we feel that is going?
 
 That sounds great. I hope so.
 
 One way to create a separate group to manage the zmq driver is to move
 it to a separate repository. Is the internal API for messaging drivers
 stable enough to do that?
 
 Actually I'm not intended to move it to a separate repository. I just
 want to make sure if it is possible to make a fixed online meeting for
 zmq driver.

And personally I'd prefer not to split the repo.  I'd rather explore the
idea of driver maintainers whose +1 on driver code counts as +2, like we
had/have with incubator.  Splitting the repo brings up some sticky
issues with requirements syncs and such.  I'd like to think that with
only three different drivers we don't need the overhead of managing
separate repos, but maybe I'm being optimistic. :-)

Kind of off topic since that's not what is being proposed here, but two
different people have mentioned it so I wanted to note my preference in
case it comes up again.

-Ben

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

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

2015-03-24 Thread Jeremy Stanley

On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote:
[...]
 I'm really not a fan of the Defcore effort. This should come as no
 surprise to anyone. I've been quite blunt about my disdain for the
 focus on identifying which API things are mandatory and which are
 optional, in order to say some vendor's product is OpenStack.
[...]

Understandable--and I'm certainly no fan of bureaucracy and
politicking--just pointing out that in the carrots-and-sticks bin we
have trademarks as a potential carrot to encourage people running
OpenStack commercially to further the goals of our community. If
there is broad community support for the idea that standard
OpenStack APIs should not be arbitrarily extended downstream because
it hurts interoperability, then this might be one way to improve the
situation. If there are other means to achieve this then they too
should be considered, obviously.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Li Ma

On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote:
 The goal we set at the Kilo summit was to have a group of people
 interested in zmq start contributing to the driver, and I had hoped to
 the library overall. How do we feel that is going?

That sounds great. I hope so.

 One way to create a separate group to manage the zmq driver is to move
 it to a separate repository. Is the internal API for messaging drivers
 stable enough to do that?

Actually I'm not intended to move it to a separate repository. I just
want to make sure if it is possible to make a fixed online meeting for
zmq driver.

-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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

Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions

2015-03-24 Thread Yee, Guang

++

Same here.

From: Marek Denis [mailto:marek.de...@cern.ch]
Sent: Tuesday, March 24, 2015 1:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions

Hi,

I strongly support this request.
On 23.03.2015 22:42, Steve Martinelli wrote:
I'd like to request an exemption for the following to go into the Kilo release.

This work is crucial for:
-  Keystone to Keystone communication. An ECP wrapped SAML assertion will make 
it much easier for consumers and clients to use the K2K feature in Keystone. 
Currently, a client must take the generated SAML response and must prepare the 
ECP envelope themselves. This should be handled by Keystone, and not the 
clients. The client should be able to ask for the ECP wrapped assertion and 
hand it off to another Keystone.

Why this needs an FFE?
- To properly created an ECP wrapped a SAML assertion, a relay state property 
must be known, (as it's used to compute a value in an ECP specific field). This 
depends on how the service provider has their mod_shib configured. We will need 
to add a new property to the keystone resource 'service provider' - the spec 
change is here: https://review.openstack.org/#/c/166086/

Status of the work:
- The patches necessary for this feature already and split into two patches. 1) 
To add a new relay_state_prefix property to the service provider resource: 
https://review.openstack.org/#/c/166078/ and 2) to actually use this new 
property in order to generate the ECP assertion: 
https://review.openstack.org/#/c/162866/

Thanks,

Steve Martinelli
OpenStack Keystone Core


Marek Denis
OpenStack Keystone Core
__
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] Fwd: PCI passthrough of 40G ethernet interface

2015-03-24 Thread yongli he


在 2015年03月11日 22:15, jacob jacob 写道:
Hi, jacob

I'm trying  to find someone to check it, if there any feed back, i 
update you.


Yongli He


-- Forwarded message --
From: *jacob jacob* opstk...@gmail.com mailto:opstk...@gmail.com
Date: Tue, Mar 10, 2015 at 6:00 PM
Subject: PCI passthrough of 40G ethernet interface
To: openst...@lists.openstack.org mailto:openst...@lists.openstack.org



Hi,
I'm interested in finding out if anyone has successfully tested PCI 
passthrough functionality for 40G interfaces in Openstack(KVM hypervisor).


I am trying this out on a Fedora 21 host  with Fedora 21 VM 
image.(3.18.7-200.fc21.x86_64)


Was able to successfully test PCI passthrough of 10 G interfaces:
  Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ 
Network Connection (rev 01)


With 40G interface testing, the PCI device is passed through to the VM 
but data transfer is failing.
0a:00.1 Ethernet controller: Intel Corporation Ethernet Controller 
XL710 for 40GbE QSFP+ (rev 01)


Tried this with both the i40e driver and latest dpdk driver but no 
luck so far.


With the i40e driver, the data transfer fails.
 Relevant dmesg output:
 [   11.544088] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None
[   11.689178] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None

[   16.704071] [ cut here ]
[   16.705053] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 
dev_watchdog+0x23e/0x250()

[   16.705053] NETDEV WATCHDOG: eth1 (i40e): transmit queue 1 timed out
[   16.705053] Modules linked in: cirrus ttm drm_kms_helper i40e drm 
ppdev serio_raw i2c_piix4 virtio_net parport_pc ptp virtio_balloon 
crct10dif_pclmul pps_core parport pvpanic crc32_pclmul 
ghash_clmulni_intel virtio_blk crc32c_intel virtio_pci virtio_ring 
virtio ata_generic pata_acpi
[   16.705053] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.18.7-200.fc21.x86_64 #1
[   16.705053] Hardware name: Fedora Project OpenStack Nova, BIOS 
1.7.5-20140709_153950- 04/01/2014
[   16.705053]   2e5932b294d0c473 88043fc83d48 
8175e686
[   16.705053]   88043fc83da0 88043fc83d88 
810991d1
[   16.705053]  88042958f5c0 0001 88042865f000 
0001

[   16.705053] Call Trace:
[   16.705053]  IRQ  [8175e686] dump_stack+0x46/0x58
[   16.705053]  [810991d1] warn_slowpath_common+0x81/0xa0
[   16.705053]  [81099245] warn_slowpath_fmt+0x55/0x70
[   16.705053]  [8166e62e] dev_watchdog+0x23e/0x250
[   16.705053]  [8166e3f0] ? dev_graft_qdisc+0x80/0x80
[   16.705053]  [810fd52a] call_timer_fn+0x3a/0x120
[   16.705053]  [8166e3f0] ? dev_graft_qdisc+0x80/0x80
[   16.705053]  [810ff692] run_timer_softirq+0x212/0x2f0
[   16.705053]  [8109d7a4] __do_softirq+0x124/0x2d0
[   16.705053]  [8109db75] irq_exit+0x125/0x130
[   16.705053]  [817681d8] smp_apic_timer_interrupt+0x48/0x60
[   16.705053]  [817662bd] apic_timer_interrupt+0x6d/0x80
[   16.705053]  EOI  [811005c8] ? hrtimer_start+0x18/0x20
[   16.705053]  [8105ca96] ? native_safe_halt+0x6/0x10
[   16.705053]  [810f81d3] ? rcu_eqs_enter+0xa3/0xb0
[   16.705053]  [8101ec7f] default_idle+0x1f/0xc0
[   16.705053]  [8101f64f] arch_cpu_idle+0xf/0x20
[   16.705053]  [810dad35] cpu_startup_entry+0x3c5/0x410
[   16.705053]  [8104a2af] start_secondary+0x1af/0x1f0
[   16.705053] ---[ end trace 7bda53aeda558267 ]---
[   16.705053] i40e :00:05.0 eth1: tx_timeout recovery level 1
[   16.705053] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx 
ring 0 disable timeout
[   16.744198] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx 
ring 64 disable timeout

[   16.779322] i40e :00:05.0: i40e_ptp_init: added PHC on eth1
[   16.791819] i40e :00:05.0: PF 40 attempted to control timestamp 
mode on port 1, which is owned by PF 1
[   16.933869] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None
[   18.853624] SELinux: initialized (dev tmpfs, type tmpfs), uses 
transition SIDs

[   22.720083] i40e :00:05.0 eth1: tx_timeout recovery level 2
[   22.826993] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx 
ring 0 disable timeout
[   22.935288] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx 
ring 64 disable timeout

[   23.669555] i40e :00:05.0: i40e_ptp_init: added PHC on eth1
[   23.682067] i40e :00:05.0: PF 40 attempted to control timestamp 
mode on port 1, which is owned by PF 1
[   23.722423] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full 
Duplex, Flow Control: None

[   23.800206] i40e :00:06.0: i40e_ptp_init: added PHC on eth2
[   23.813804] i40e :00:06.0: PF 48 attempted to control timestamp 
mode on port 0, which is owned by PF 0
[   23.855275] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full 
Duplex, Flow

Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI

2015-03-24 Thread yongli he


在 2015年03月07日 04:59, Chris Friesen 写道:
Hi...it would be good to test a bunch of the 
hugepages/pinning/multi-numa-node-guests/etc. features with real 
hardware.  The normal testing doesn't cover much of that since it's 
hardware-agnostic.



we had another team build up a Networking CI for this purposes.

networking CI(commenting to Neutron) - 
https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-Networking-CI

Yongli He



Chris


On 01/07/2015 08:31 PM, yongli he wrote:

Hi,

Intel  set up a Hardware based Third Part CI.   it's already running 
sets of PCI

test cases
for several  weeks (do not sent out comments, just log the result)
the log server and these test cases seems fairly stable now. to begin 
given

comments  to nova
repository,  what other necessary work need to be address?

Details:
1. ThirdPartySystems 
https://wiki.openstack.org/wiki/ThirdPartySystems Information

https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI

2. a sample logs:
http://192.55.68.190/143614/6/ cid:part2.01090706.06060904@intel.com

http://192.55.68.190/143614/6/

http://192.55.68.190/139900/4

http://192.55.68.190/143372/3/

http://192.55.68.190/141995/6/

http://192.55.68.190/137715/13/

http://192.55.68.190/133269/14/

3. Test cases on github:
https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases 





Thanks
Yongli He



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




__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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




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

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Li Ma

By the way, just informing that a general session will be available
for zeromq driver. I'll provide the general architecture of the
current zeromq driver, pros and cons, potential improvements, use
cases for production.

Topic: Distributed Messaging System for OpenStack at Scale
Link: http://sched.co/2qpe

On Wed, Mar 25, 2015 at 9:31 AM, Doug Hellmann d...@doughellmann.com wrote:
 Excerpts from ozamiatin's message of 2015-03-24 18:57:25 +0200:
 Hi,
 +1 for subgroup meeting

 Does the separate repository mean separate library (python package) with
 its own release cycles so on?

 Yes, although as an Oslo library it would be subject to our existing
 policies about versioning, releases, etc.


 As I can see the separate library makes it easy:

 1) To support optional (for oslo.messaging) requirements specific for
 zmq driver like pyzmq, redis so on
 2) Separate zmq testing. Now we have hacks like skip_test_if_nozmq or
 something like that.

 Disadvantages are:
 1) Synchronization changes with oslo.messaging (Changes to the
 oslo.messaging API may break all things)

 That's a good point. I think the neutron team is using a shim layer
 in-tree to mitigate driver API changes, with most of the driver
 implementation in a separate repository. Doing something like that here
 might make sense.

 That said, a separate repository is only one possible approach.
 Since most of the other Oslo cores seem to not like the idea of
 splitting the driver out, so we shouldn't assume it's going to
 happen.

 2) Additional effort for separate library management (releases so on)

 As for me, I like the idea of separate repo for zmq driver because it
 gives more freedom for driver extension.
 There are some ideas that we can have more than a single zmq driver
 implementation in future.
 At least we may have different versions one for HA and one for
 scalability based on different zmq patterns.


 Thanks,
 Oleksii Zamiatin

 On 24.03.15 18:03, Ben Nemec wrote:
  On 03/24/2015 10:31 AM, Li Ma wrote:
  On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com 
  wrote:
  The goal we set at the Kilo summit was to have a group of people
  interested in zmq start contributing to the driver, and I had hoped to
  the library overall. How do we feel that is going?
  That sounds great. I hope so.
 
  One way to create a separate group to manage the zmq driver is to move
  it to a separate repository. Is the internal API for messaging drivers
  stable enough to do that?
  Actually I'm not intended to move it to a separate repository. I just
  want to make sure if it is possible to make a fixed online meeting for
  zmq driver.
  And personally I'd prefer not to split the repo.  I'd rather explore the
  idea of driver maintainers whose +1 on driver code counts as +2, like we
  had/have with incubator.  Splitting the repo brings up some sticky
  issues with requirements syncs and such.  I'd like to think that with
  only three different drivers we don't need the overhead of managing
  separate repos, but maybe I'm being optimistic. :-)
 
  Kind of off topic since that's not what is being proposed here, but two
  different people have mentioned it so I wanted to note my preference in
  case it comes up again.
 
  -Ben
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 __
 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



-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Zhou, Zhenzan

Hi,

To check LOADED(or ENABLED) data source drivers for a running system, you can 
use congress cli. Maybe we could add a command to list SUPPORTED data source 
drivers?

zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id   | name  | enabled | type | config

  |
+--+---+-+--+-+
| 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 7326d165-9e03-4b9c-acf8-b94a7f0a013f | ironic| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 80587cf8-ffbc-4c9a-b452-f884427b8cac | keystone  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 9a85d0f9-c869-41fe-b6d0-b784c1e84169 | nova  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| df715798-7aa9-4fdc-8bfd-f37718bd4691 | neutronv2 | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| e819b6c4-3744-4c45-9623-ad26ead15485 | glancev2  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
+--+---+-+--+-+

zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show cinder
+---++
| table | columns|
+---++
| services  | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'binary', 'description': 'None'}, |
|   | {'name': 'zone', 'description': 'None'},   |
|   | {'name': 'state', 'description': 'None'},  |
|   | {'name': 'updated_at', 'description': 'None'}, |
|   | {'name': 'host', 'description': 'None'},   |
|   | {'name': 'disabled_reason', 'description': 'None'} |
|   ||
| snapshots | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'created_at', 'description': 'None'}, |
|   | {'name': 'volume_id', 'description': 'None'},  |
|   | {'name': 'size', 'description': 'None'},   |
|   | {'name': 'id', 'description': 'None'}, |
|   | {'name': 'name', 'description': 'None'}|
|   ||
| volumes   | {'name': 'id', 'description': 'None'}, |
|   | {'name': 'size', 'description': 'None'},   |
|   | {'name': 'user_id', 'description': 'None'},|
|   | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'description', 'description': 'None'},|
|   | {'name': 'name', 'description': 'None'},   |
|   | {'name': 'bootable', 'description': 'None'},   |
|   | {'name': 'created_at', 'description': 'None'}, |
|   | {'name': 'volume_type', 'description': 'None'} |
|   ||
+---++


BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:thinri...@vmware.com]
Sent: Wednesday, March 25, 2015 6:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan,

I wish we could claim Congress has most of the data from OpenStack APIs already 
available for policy, but that's not the case today.

If it were me, I'd start with your use cases, figure out which services and API 
calls you'll need to support those use cases, and then check if those APIs are 
already available in Congress.

Tim

On Mar 24, 2015, at 1:47 PM, Bryan Sullivan 
bls...@hotmail.commailto:bls...@hotmail.com wrote:

Thanks for clarifying, Tim (and Alex for the other response).

Since I have to

[openstack-dev] [Nova] availabilityzone's validation with foce_host

Hi, guys,

Currently, I'm working on the bug[1], and this is my patch[2] for that.
But there's a small issue I'm not very sure about the workaround.

The AZ will be valided to ensure its existence according to my patch,
whether or not the user specify a force host. However, if force_host
doesn't belong to the AZ, AvailabilityZoneFilter will fail. but the
problem still exists if AvailabilityZoneFilter is not configed.

So, should the force_host validation be needed, toghether with the AZ
validation? or we just let it go and wait for the filter failure?

[1]: https://launchpad.net/bugs/1431194
[2]: https://review.openstack.org/#/c/163842/

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

2015-03-24 Thread Guo, Ruijing

I am trying to understand how guest os use trunking network.

If guest os use bridge like Linuxbride and OVS, how we launch it and how 
libvirt to support it?

Thanks,
-Ruijing


From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Wednesday, March 25, 2015 2:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

That spec ensures that you can tell what the plugin is doing.  You can ask for 
a VLAN transparent network, but the cloud may tell you it can't make one.

The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the spec 
you're referring to doesn't change that.  The spec does ensure that if you try 
and create a VLAN trunk on a cloud that uses the OVS driver, you'll be told you 
can't.  in the future, the OVS driver can be fixed, but that's how things stand 
at present.  Fixing the OVS driver really involves getting in at the OVS flow 
level - can be done, but we started with the basics.
If you want to use a VLAN trunk using the current code, I recommend VXLAN or 
GRE along with the Linuxbridge driver, both of which support VLAN transparent 
networking.  If they're configured and you ask for a VLAN trunk you'll be told 
you got one.
--
Ian.


On 24 March 2015 at 09:43, Daniele Casini 
daniele.cas...@dektech.com.aumailto:daniele.cas...@dektech.com.au wrote:
Hi all:

in reference to the following specification about the creation of VLAN trunking 
network for NFV

https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst

I would like to better understand how the tagged traffic will be realized. In 
order to explain myself, I report the following use case:

A VNF is deployed in one VM, which has a trunk port carrying traffic for two 
VLANs over a single link able to transport more than one VLAN through a single 
integration-bridge (br-int) port. So, How does br-int manage the VLAN-ID? In 
other words, what are the action performed by the br-int when a VM forwards 
traffic to another host?
Does it put an additional tag or replace the existing one keeping the match 
with a table or something like that?

Thank you very much.

Daniele


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Beyond IRC (was Re: Cinder Third-Party CI: what next?)

Excerpts from Stefano Maffulli's message of 2015-03-24 15:13:09 -0700:
 On Tue, 2015-03-24 at 19:01 +, Rochelle Grober wrote:
  So, how do we get timely first core review of patches in areas of the
  world where Core presence in IRC is slim to none?
 
 I think that most core reviewers use bouncers, so notifying them in the
 channel would probably raise a notification in their clients when they
 connect back. I understand the feeling though: as the sender of a
 message over IRC, I have no good way to understand if the message was
 delivered to the recipient as expected.
 
 I'd start with advising to use the bouncer and ping the core reviewers
 on channel with review requests. (more about this below)
  
  I can think of a few options but they don’t seem great:  
  
  ·A filter for dashboards that flags reviews with multiple +1s
  and no core along with a commitment of the Core team to perform a
  review within x number of days
  
 This might work, modulo the 'committment' of core team which I think
 cannot go above a best effort.

We have a few dashboards like this for Oslo:
https://wiki.openstack.org/wiki/Oslo#Review_Links

 
  ·A separate mailing list for project review requests
 
 I'm skeptical about this being effective: just another source of
 incoming email that needs to be filtered out (at which point a mailman
 topic would have the same effect).

Yes, email notifications scale poorly for really active reviewers.
Between gerrit and launchpad, there is already a lot of notification
email being filtered out of inboxes.

 
  ·Somehow queueing requests in the IRC channel so that offline
  developers can easily find review requests when looking at channel
  logs
 
 Maybe we can hack an IRC bot so that it collects review requests and
 lists them on eavesdrop? Something like a user on irc writes:
 
 : please review https://URL because it's needed for GOODREASONS #review
 
 and on a web page like http://eavesdrop.openstack.org/ we add 'requests
 for reviews', maybe an rss feed.

We have a section of the weekly Oslo meeting dedicated to discussing
reviews that need to be prioritized. Anyone can add an item to the
agenda, even if they aren't present at the meeting. (I don't think
that was an original idea, but I'm not sure where I saw it first
so I can't give credit properly.)

 
 BTW, Thierry had a similar request a few weeks back for a system to
 quickly share 'good news' and create a stream of reasons for
 happyness :)

++

  
  Solving this issue could help not just Third Party developers, but all
  of OpenStack and make the community more inviting to Asian and
  Australian (and maybe European and African) developers.
 
 In general, make it more resilient and asynchronous, not just because of
 timezones.
 
 /stef
 

__
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 Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Monty Taylor

On 03/24/2015 06:05 PM, Kyle Mestery wrote:
 On Tue, Mar 24, 2015 at 9:56 AM, Doug Hellmann d...@doughellmann.com
 wrote:
 
 Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400:

 Echoing both Thierry and John.  I support Mike’s decision to enforce the
 requirement. Maintaining drivers in the tree comes with responsibilities to
 the community and 3rd party CI is one of the them.  Mike enforcing this
 requirement was the right action even if a hard one to take.

 mark

 Indeed. The deadlines were communicated clearly, and frequently.
 Making phone calls to reach out to contributors for issues like
 this is exceptional.

 +1000. Enabling contributors is great, but CI systems are an important
 part of that enablement. I appreciate what Mike has done to drive Cinder
 towards a quality level for all contributors here. It's a hard stance to
 take, but saying No can sometimes be the right decision.

I'm just going to pile on.

People keep asking us to focus on quality over landing features. It was
the #1 request from EVERY operator at the recent Ops summit. This is one
of that facets of doing that. It's hard, and it doesn't always feel good
to all the parties involved - but it's important.

Thank you, Mike, for sticking to your deadline. OpenStack will be better
for it.

If it's not tested, it's broken

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

Re: [openstack-dev] [neutron] FF and our march towards the RC

2015-03-24 Thread Kyle Mestery

On Tue, Mar 24, 2015 at 5:30 PM, Itsuro ODA o...@valinux.co.jp wrote:

 Kyle and cores,

 There are some fixes [1] I want to get merged in kilo-rc1.
 (These fixes stay for a long time on gerrit because
  they have not gained core's review much.)

 I'd like to set milestone to kilo-rc1 for these fixes but
 I can't set milestone field of launchpad.

 I wish cores are interested in these fix and support to
 get merged.

 Thanks for bringing these to my attention Itsuro. I've marked them as RC1
for now.


 [1]
 * https://review.openstack.org/147032/
   (see also:
 http://lists.openstack.org/pipermail/openstack-dev/2015-March/059466.html
 )
 * https://review.openstack.org/161947/
 * https://review.openstack.org/150284/
 * https://review.openstack.org/149458/

 Thanks.
 Itsuro Oda

 On Tue, 24 Mar 2015 12:12:58 -0500
 Kyle Mestery mest...@mestery.com wrote:

  Folks:
 
  I've gone through the BPs granted an FFE and I have our RC-1 setup now
 [1].
  Please note that the BPs in there all need to merge by the dates
 specified
  in the BP in Launchpad. Most are by next Tuesday, March 31. But the LBaaS
  drivers need to go in by Friday. If these BPs don't land by then, they'll
  be out of Kilo. We need a solid 2 weeks to work on bugs that crop up as
  we're testing Neutron Kilo.
 
  I'll be working the bug list next. If you feel a bug should be a release
  candidate, target it to RC1 for now.
 
  Core Reviewers: Please be cautious about merging code at this point. When
  in doubt, find me in #openstack-neutron.
 
  Thanks!
  Kyle
 
  [1] https://launchpad.net/neutron/+milestone/kilo-rc1

 --
 Itsuro ODA o...@valinux.co.jp


 __
 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] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Pierre-Emmanuel Ettori

Hi Zhenzan,
Actually I believe the command that Tim is looking for is:
openstack congress datasource list

Please let us know if you are running into any issue.

Thanks
Pierre

On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs thinri...@vmware.com wrote:

  Hi Zhenzan,


  I don't have the CLI in front of me, but check out the 'driver'
 commands.  The command you're looking for is something like the following.


  $ openstack congress driver list



  Tim


  --
 *From:* Zhou, Zhenzan zhenzan.z...@intel.com
 *Sent:* Tuesday, March 24, 2015 7:39 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Congress] Info on Currently Supported
 Data Drivers

 Hi,



 To check LOADED(or ENABLED) data source drivers for a running system, you
 can use congress cli. Maybe we could add a command to list SUPPORTED data
 source drivers?



 zhenzan@zhenzan-openstack:~$ openstack congress datasource list


 +--+---+-+--+-+

 | id   | name  | enabled | type |
 config
 |


 +--+---+-+--+-+

 | 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |

 | 7326d165-9e03-4b9c-acf8-b94a7f0a013f | ironic| True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |

 | 80587cf8-ffbc-4c9a-b452-f884427b8cac | keystone  | True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |

 | 9a85d0f9-c869-41fe-b6d0-b784c1e84169 | nova  | True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |

 | df715798-7aa9-4fdc-8bfd-f37718bd4691 | neutronv2 | True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |

 | e819b6c4-3744-4c45-9623-ad26ead15485 | glancev2  | True| None |
 {u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',
 u'auth_url': u'http://10.239.47.118:5000/v2.0'} |


 +--+---+-+--+-+



 zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show
 cinder

 +---++

 | table | columns|

 +---++

 | services  | {'name': 'status', 'description': 'None'}, |

 |   | {'name': 'binary', 'description': 'None'}, |

 |   | {'name': 'zone', 'description': 'None'},   |

 |   | {'name': 'state', 'description': 'None'},  |

 |   | {'name': 'updated_at', 'description': 'None'}, |

 |   | {'name': 'host', 'description': 'None'},   |

 |   | {'name': 'disabled_reason', 'description': 'None'} |

 |   ||

 | snapshots | {'name': 'status', 'description': 'None'}, |

 |   | {'name': 'created_at', 'description': 'None'}, |

 |   | {'name': 'volume_id', 'description': 'None'},  |

 |   | {'name': 'size', 'description': 'None'},   |

 |   | {'name': 'id', 'description': 'None'}, |

 |   | {'name': 'name', 'description': 'None'}|

 |   ||

 | volumes   | {'name': 'id', 'description': 'None'}, |

 |   | {'name': 'size', 'description': 'None'},   |

 |   | {'name': 'user_id', 'description': 'None'},|

 |   | {'name': 'status', 'description': 'None'}, |

 |   | {'name': 'description', 'description': 'None'},|

 |   | {'name': 'name', 'description': 'None'},   |

 |   | {'name': 'bootable', 'description': 'None'},   |

 |   | {'name': 'created_at', 'description': 'None'}, |

 |   | {'name': 'volume_type', 'description': 'None'} |

 |   ||

 +---++





 BR

 Zhou Zhenzan



 *From:* Tim Hinrichs

Re: [openstack-dev] [all] creating stable branches for all libraries, Oslo, client, and other

Excerpts from Joe Gordon's message of 2015-03-24 14:22:03 -0700:
 On Tue, Mar 24, 2015 at 1:13 PM, Doug Hellmann d...@doughellmann.com
 wrote:
 
  We have a cross-project spec up for review discussing a change in the
  release process precipitated by the fact that we are now capping library
  versions in stable branch test configurations. We’ve talked about it a
  couple of times at the cross-project meetings, but we also want to make
  sure it is widely seen because it will affect the way bug fixes need to be
  managed in client libraries (new releases of clients won’t automatically
  make it into stable branches, and we will need to maintain stable branches
  of the clients with back-ports for critical fixes).
 
 Here is a real case where the correct fix is a stable branch for a client:
 https://bugs.launchpad.net/python-glanceclient/+bug/1423165

That's a great concrete example, Joe, thanks.

Doug

 
  The Oslo team has already followed this procedure, including releasing
  some versions of libraries with backports for the stable branches. I think
  most of the wrinkles are therefore worked out, and I would like to move
  ahead with this for all projects that release library-like artifacts for
  Kilo, understanding that we might need to update the document, procedures,
  and tools as we go.
 
  Please take a few minutes to read the spec:
  https://review.openstack.org/#/c/155072/
 
  Thanks,
  Doug
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

Excerpts from ozamiatin's message of 2015-03-24 18:57:25 +0200:
 Hi,
 +1 for subgroup meeting
 
 Does the separate repository mean separate library (python package) with 
 its own release cycles so on?

Yes, although as an Oslo library it would be subject to our existing
policies about versioning, releases, etc.

 
 As I can see the separate library makes it easy:
 
 1) To support optional (for oslo.messaging) requirements specific for 
 zmq driver like pyzmq, redis so on
 2) Separate zmq testing. Now we have hacks like skip_test_if_nozmq or 
 something like that.
 
 Disadvantages are:
 1) Synchronization changes with oslo.messaging (Changes to the 
 oslo.messaging API may break all things)

That's a good point. I think the neutron team is using a shim layer
in-tree to mitigate driver API changes, with most of the driver
implementation in a separate repository. Doing something like that here
might make sense.

That said, a separate repository is only one possible approach.
Since most of the other Oslo cores seem to not like the idea of
splitting the driver out, so we shouldn't assume it's going to
happen.

 2) Additional effort for separate library management (releases so on)
 
 As for me, I like the idea of separate repo for zmq driver because it 
 gives more freedom for driver extension.
 There are some ideas that we can have more than a single zmq driver 
 implementation in future.
 At least we may have different versions one for HA and one for 
 scalability based on different zmq patterns.
 
 
 Thanks,
 Oleksii Zamiatin
 
 On 24.03.15 18:03, Ben Nemec wrote:
  On 03/24/2015 10:31 AM, Li Ma wrote:
  On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com 
  wrote:
  The goal we set at the Kilo summit was to have a group of people
  interested in zmq start contributing to the driver, and I had hoped to
  the library overall. How do we feel that is going?
  That sounds great. I hope so.
 
  One way to create a separate group to manage the zmq driver is to move
  it to a separate repository. Is the internal API for messaging drivers
  stable enough to do that?
  Actually I'm not intended to move it to a separate repository. I just
  want to make sure if it is possible to make a fixed online meeting for
  zmq driver.
  And personally I'd prefer not to split the repo.  I'd rather explore the
  idea of driver maintainers whose +1 on driver code counts as +2, like we
  had/have with incubator.  Splitting the repo brings up some sticky
  issues with requirements syncs and such.  I'd like to think that with
  only three different drivers we don't need the overhead of managing
  separate repos, but maybe I'm being optimistic. :-)
 
  Kind of off topic since that's not what is being proposed here, but two
  different people have mentioned it so I wanted to note my preference in
  case it comes up again.
 
  -Ben
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

__
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] [OpenStack-DefCore] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Forwarded from Rob Hirschfeld, Co-chair of DefCore committee

-Original Message-
From: Rob Hirschfeld [mailto:r...@zehicle.com] 
Sent: Tuesday, March 24, 2015 18:50
To: Rochelle Grober; OpenStack Development Mailing List (not for usage 
questions)
Cc: defcore-commit...@lists.openstack.org
Subject: Re: [OpenStack-DefCore] [openstack-dev] [nova][api] Microversions. And 
why do we need API extensions for new API functionality?

Sorry for replying at the top

Rocky - thanks for bringing this to the DefCore list

Jeremy - +1, the process has mechanisms to address these question and I 
believe your position (extensions are not required) is reflected in the 
2015.03 guideline.  I recall removing one of the capabilities at the 
DefCore face-to-face specifically for that reason.

Jay - it's not clear to me if you object to the fact that we are 
required by the by-laws to enforce the trademark or about the way that 
we've constructed the process to meet that obligation.  If the later, 
suggestions about improving are always welcome directly or via your TC 
DefCore delegates (Russell  Monty)

DefCore's weekly meeting is tomorrow at 9am PT.  Details: 
https://etherpad.openstack.org/p/DefCoreScale.9

Rob

On 03/24/2015 06:44 PM, Rochelle Grober wrote:

 Jeremy Stanley on March 24, 2015 07:28 wrote:
 On 2015-03-24 10:10:07 -0400 (-0400), Jay Pipes wrote:
 [...]
 I'm really not a fan of the Defcore effort. This should come as no
 surprise to anyone. I've been quite blunt about my disdain for the
 focus on identifying which API things are mandatory and which are
 optional, in order to say some vendor's product is OpenStack.
 [...]

 Understandable--and I'm certainly no fan of bureaucracy and
 politicking--just pointing out that in the carrots-and-sticks bin we
 have trademarks as a potential carrot to encourage people running
 OpenStack commercially to further the goals of our community. If
 there is broad community support for the idea that standard
 OpenStack APIs should not be arbitrarily extended downstream because
 it hurts interoperability, then this might be one way to improve the
 situation. If there are other means to achieve this then they too
 should be considered, obviously.

 [Rockyg] Tl;dr.  Propose it to DefCore.  They might agree.  But they might 
 have action items for developers to make it actionable on DefCore's part.

 Hey, it sounds like a reasonable request to me, and it's a large operator 
 making the request for DefCore to recognize that extensions break 
 interoperability.  Plus, Defcore specifically states that vendor specific 
 code within OpenStack is not considered for inclusion in the Defcore 
 capabilities/test/designated code sets.

 So then the questions become:

 * Are there any currently included capabilities that assume extensions work?
 * Are there any likely candidates for future Defcore sets that assume 
 extensions work?
 * Will extensions be deprecated before capabilities requiring extensions are 
 in the candidate pool?
 * Once extensions are deprecated, or it is known that nothing in Defcore sets 
 include the ability to use extensions, are there tests which will validate 
 that extensions are not part of the cloud under test?

 Something to think about, and if you are serious about limiting the negative 
 effects of extensions, it is certainly worth proposing their elimination 
 and/or restrictions on them to Defcore.

 And an FYI, APIs and tests are not chosen by DefCore because they are 
 meaningful, but because they are measurable.  DefCore uses User Surveys (and 
 who knows what else) to determine adoption rates of OpenStack capabilities 
 that are then converted to APIs and tests, etc.  If you have a implementable 
 ideas on how better to measure individual clouds/cloud products against the 
 user communities' utilization, they'd love to hear from you.  No, really. 
 DefCore wants to hear of better ways to ensure that clouds with the OpenStack 
 trademark mean that user implementations on those clouds are portable across 
 compliant vendors within the scope of what those vendors advertise.

 --rocky

-- 

Rob

Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge  ravolt

__
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] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Tim Hinrichs

Hi Zhenzan,


I don't have the CLI in front of me, but check out the 'driver' commands.  The 
command you're looking for is something like the following.


$ openstack congress driver list



Tim



From: Zhou, Zhenzan zhenzan.z...@intel.com
Sent: Tuesday, March 24, 2015 7:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi,

To check LOADED(or ENABLED) data source drivers for a running system, you can 
use congress cli. Maybe we could add a command to list SUPPORTED data source 
drivers?

zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id   | name  | enabled | type | config

  |
+--+---+-+--+-+
| 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 7326d165-9e03-4b9c-acf8-b94a7f0a013f | ironic| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 80587cf8-ffbc-4c9a-b452-f884427b8cac | keystone  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 9a85d0f9-c869-41fe-b6d0-b784c1e84169 | nova  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| df715798-7aa9-4fdc-8bfd-f37718bd4691 | neutronv2 | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| e819b6c4-3744-4c45-9623-ad26ead15485 | glancev2  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
+--+---+-+--+-+

zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show cinder
+---++
| table | columns|
+---++
| services  | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'binary', 'description': 'None'}, |
|   | {'name': 'zone', 'description': 'None'},   |
|   | {'name': 'state', 'description': 'None'},  |
|   | {'name': 'updated_at', 'description': 'None'}, |
|   | {'name': 'host', 'description': 'None'},   |
|   | {'name': 'disabled_reason', 'description': 'None'} |
|   ||
| snapshots | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'created_at', 'description': 'None'}, |
|   | {'name': 'volume_id', 'description': 'None'},  |
|   | {'name': 'size', 'description': 'None'},   |
|   | {'name': 'id', 'description': 'None'}, |
|   | {'name': 'name', 'description': 'None'}|
|   ||
| volumes   | {'name': 'id', 'description': 'None'}, |
|   | {'name': 'size', 'description': 'None'},   |
|   | {'name': 'user_id', 'description': 'None'},|
|   | {'name': 'status', 'description': 'None'}, |
|   | {'name': 'description', 'description': 'None'},|
|   | {'name': 'name', 'description': 'None'},   |
|   | {'name': 'bootable', 'description': 'None'},   |
|   | {'name': 'created_at', 'description': 'None'}, |
|   | {'name': 'volume_type', 'description': 'None'} |
|   ||
+---++


BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:thinri...@vmware.com]
Sent: Wednesday, March 25, 2015 6:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Bryan,

I wish we could claim Congress has most of the data

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Zhou, Zhenzan

Hi,

The ‘driver list’ sub command could provide supported data source drivers, but 
we cannot show its schema if it’s NOT LOADED. So we still have to check the 
code for the schema. My point is that we could support show schemas for any 
supported data source drivers, even it’s not loaded.

zhenzan@zhenzan-openstack:~$ openstack congress driver list
++--+
| id | description  
|
++--+
| ceilometer | Datasource driver that interfaces with ceilometer.   
|
| plexxi | Datasource driver that interfaces with PlexxiCore.   
|
| swift  | Datasource driver that interfaces with swift.
|
| neutronv2  | Datasource driver that interfaces with OpenStack Networking 
aka Neutron. |
| nova   | Datasource driver that interfaces with OpenStack Compute aka 
nova.   |
| murano | Datasource driver that interfaces with murano
|
| keystone   | Datasource driver that interfaces with keystone. 
|
| cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry  
|
| ironic | Datasource driver that interfaces with OpenStack bare metal 
aka ironic.  |
| cinder | Datasource driver that interfaces with OpenStack cinder. 
|
| vcenter| Datasource driver that interfaces with vcenter   
|
| glancev2   | Datasource driver that interfaces with OpenStack Images aka 
Glance.  |
++--+
zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show 
ceilometer
ERROR: openstack Resource ceilometer not found (HTTP 404)


BR
Zhou Zhenzan
From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com]
Sent: Wednesday, March 25, 2015 11:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Zhenzan,
Actually I believe the command that Tim is looking for is:
openstack congress datasource list

Please let us know if you are running into any issue.

Thanks
Pierre

On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

Hi Zhenzan,



I don't have the CLI in front of me, but check out the 'driver' commands.  The 
command you're looking for is something like the following.



$ openstack congress driver list



Tim




From: Zhou, Zhenzan zhenzan.z...@intel.commailto:zhenzan.z...@intel.com
Sent: Tuesday, March 24, 2015 7:39 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers
Hi,

To check LOADED(or ENABLED) data source drivers for a running system, you can 
use congress cli. Maybe we could add a command to list SUPPORTED data source 
drivers?

zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id   | name  | enabled | type | config

  |
+--+---+-+--+-+
| 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 7326d165-9e03-4b9c-acf8-b94a7f0a013f | ironic| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 80587cf8-ffbc-4c9a-b452-f884427b8cac | keystone  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 9a85d0f9-c869-41fe-b6d0-b784c1e84169 | nova  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| df715798-7aa9-4fdc-8bfd-f37718bd4691 | neutronv2 | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| e819b6c4-3744-4c45-9623-ad26ead15485 | glancev2  | True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden',

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Zhou, Zhenzan

Just found it has been supported, e.g.

openstack  congress driver schema show ceilometer

So here is the way to check data source drivers:

For supported data source drivers:

1.   openstack  congress driver list

2.   openstack  congress driver schema show ds-name

For enabled data source drivers:

1.   openstack congress datasource list

2.   openstack congress datasource schema show ds-name

BR
Zhou Zhenzan

From: Zhou, Zhenzan [mailto:zhenzan.z...@intel.com]
Sent: Wednesday, March 25, 2015 12:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi,

The ‘driver list’ sub command could provide supported data source drivers, but 
we cannot show its schema if it’s NOT LOADED. So we still have to check the 
code for the schema. My point is that we could support show schemas for any 
supported data source drivers, even it’s not loaded.

zhenzan@zhenzan-openstack:~$ openstack congress driver list
++--+
| id | description  
|
++--+
| ceilometer | Datasource driver that interfaces with ceilometer.   
|
| plexxi | Datasource driver that interfaces with PlexxiCore.   
|
| swift  | Datasource driver that interfaces with swift.
|
| neutronv2  | Datasource driver that interfaces with OpenStack Networking 
aka Neutron. |
| nova   | Datasource driver that interfaces with OpenStack Compute aka 
nova.   |
| murano | Datasource driver that interfaces with murano
|
| keystone   | Datasource driver that interfaces with keystone. 
|
| cloudfoundryv2 | Datasource driver that interfaces with cloudfoundry  
|
| ironic | Datasource driver that interfaces with OpenStack bare metal 
aka ironic.  |
| cinder | Datasource driver that interfaces with OpenStack cinder. 
|
| vcenter| Datasource driver that interfaces with vcenter   
|
| glancev2   | Datasource driver that interfaces with OpenStack Images aka 
Glance.  |
++--+
zhenzan@zhenzan-openstack:~$ openstack congress datasource schema show 
ceilometer
ERROR: openstack Resource ceilometer not found (HTTP 404)


BR
Zhou Zhenzan
From: Pierre-Emmanuel Ettori [mailto:pe.ett...@gmail.com]
Sent: Wednesday, March 25, 2015 11:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi Zhenzan,
Actually I believe the command that Tim is looking for is:
openstack congress datasource list

Please let us know if you are running into any issue.

Thanks
Pierre

On Tue, Mar 24, 2015 at 8:39 PM Tim Hinrichs 
thinri...@vmware.commailto:thinri...@vmware.com wrote:

Hi Zhenzan,



I don't have the CLI in front of me, but check out the 'driver' commands.  The 
command you're looking for is something like the following.



$ openstack congress driver list



Tim




From: Zhou, Zhenzan zhenzan.z...@intel.commailto:zhenzan.z...@intel.com
Sent: Tuesday, March 24, 2015 7:39 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers
Hi,

To check LOADED(or ENABLED) data source drivers for a running system, you can 
use congress cli. Maybe we could add a command to list SUPPORTED data source 
drivers?

zhenzan@zhenzan-openstack:~$ openstack congress datasource list
+--+---+-+--+-+
| id   | name  | enabled | type | config

  |
+--+---+-+--+-+
| 20a33403-e8d0-440a-b36f-0383bfcfd06f | cinder| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 7326d165-9e03-4b9c-acf8-b94a7f0a013f | ironic| True| None | 
{u'username': u'admin', u'tenant_name': u'admin', u'password': u'hidden', 
u'auth_url': u'http://10.239.47.118:5000/v2.0'} |
| 80587cf8-ffbc-4c9a-b452-f884427b8cac | keystone  | True|

[openstack-dev] [Murano] Murano agent development

2015-03-24 Thread Filip Blaha


Hello

I would like to test and debug some new features of murano agent like 
chef recipes.


I would like to know how to develop murano agent? How to test and debug 
new changes in agent code? Creating new image with every change and and 
test deployment on devstack is time-consuming and not very comfortable. 
Is there any shortcut for this development cycle?


Thanks
Filip

__
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.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Eric Windisch

From my experience, making fast moving changes is far easier when code is
split out. Changes occur too slowly when integrated.

I'd be +1 on splitting the code out. I expect you will get more done this
way.

Regards,
Eric Windisch
__
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] [sahara] Sahara + Cinder use cases?

2015-03-24 Thread Jacob Liberman


Hi,

I am working on a Sahara doc bug:
https://bugs.launchpad.net/sahara/+bug/1371360
[DOC] Features overview suggests Cinders to increase reliability

I am doing some research for this update.  What are the use cases for 
Sahara + Cinder?


1. Cinder-backed Sahara for persistent data
2. Booting Sahara instances from Cinder volumes

Can option #1 be used in conjunction with existing plugin images?

Are there any docs on using Cinder volumes in place of ephemeral?

(similar to the docs describing how to use Swift-backed EDP)

The Cinder integration test mounts a few volumes to instances but does 
not use them.


Thanks,

Jacob

__
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] zero downtime conf/kilo

2015-03-24 Thread stuart . mclaren


All,

The main zero downtime config patch has merged (thanks to everyone, especially 
Abhishek, for their help).

There's a couple of small, follow on corner case patches, that, eg ensure a config 
change to logging (INFO-DEBUG)
can be picked up dynamically.

Are we planning/hoping to merge them also? (I think it makes a better story 
than the current partial support, and could see kilo bugs
of the 'I changed tcp_keepalive and it wasn't picked up' or 'I changed the log 
level and it wasn't picked up' coming in.)

Thanks,

-Stuart

__
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.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Flavio Percoco


On 24/03/15 11:03 -0500, Ben Nemec wrote:

On 03/24/2015 10:31 AM, Li Ma wrote:

On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote:

The goal we set at the Kilo summit was to have a group of people
interested in zmq start contributing to the driver, and I had hoped to
the library overall. How do we feel that is going?


That sounds great. I hope so.


One way to create a separate group to manage the zmq driver is to move
it to a separate repository. Is the internal API for messaging drivers
stable enough to do that?


Actually I'm not intended to move it to a separate repository. I just
want to make sure if it is possible to make a fixed online meeting for
zmq driver.


And personally I'd prefer not to split the repo.  I'd rather explore the
idea of driver maintainers whose +1 on driver code counts as +2, like we
had/have with incubator.  Splitting the repo brings up some sticky
issues with requirements syncs and such.  I'd like to think that with
only three different drivers we don't need the overhead of managing
separate repos, but maybe I'm being optimistic. :-)

Kind of off topic since that's not what is being proposed here, but two
different people have mentioned it so I wanted to note my preference in
case it comes up again.


+1 I don't think this needs to be split if the only thing needed is
some extra grants. However, this is not to be forgotten in the long
run where more complex scenarious may appear.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [oslo.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread ozamiatin


Hi,
+1 for subgroup meeting

Does the separate repository mean separate library (python package) with 
its own release cycles so on?


As I can see the separate library makes it easy:

1) To support optional (for oslo.messaging) requirements specific for 
zmq driver like pyzmq, redis so on
2) Separate zmq testing. Now we have hacks like skip_test_if_nozmq or 
something like that.


Disadvantages are:
1) Synchronization changes with oslo.messaging (Changes to the 
oslo.messaging API may break all things)

2) Additional effort for separate library management (releases so on)

As for me, I like the idea of separate repo for zmq driver because it 
gives more freedom for driver extension.
There are some ideas that we can have more than a single zmq driver 
implementation in future.
At least we may have different versions one for HA and one for 
scalability based on different zmq patterns.



Thanks,
Oleksii Zamiatin

On 24.03.15 18:03, Ben Nemec wrote:

On 03/24/2015 10:31 AM, Li Ma wrote:

On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com wrote:

The goal we set at the Kilo summit was to have a group of people
interested in zmq start contributing to the driver, and I had hoped to
the library overall. How do we feel that is going?

That sounds great. I hope so.


One way to create a separate group to manage the zmq driver is to move
it to a separate repository. Is the internal API for messaging drivers
stable enough to do that?

Actually I'm not intended to move it to a separate repository. I just
want to make sure if it is possible to make a fixed online meeting for
zmq driver.

And personally I'd prefer not to split the repo.  I'd rather explore the
idea of driver maintainers whose +1 on driver code counts as +2, like we
had/have with incubator.  Splitting the repo brings up some sticky
issues with requirements syncs and such.  I'd like to think that with
only three different drivers we don't need the overhead of managing
separate repos, but maybe I'm being optimistic. :-)

Kind of off topic since that's not what is being proposed here, but two
different people have mentioned it so I wanted to note my preference in
case it comes up again.

-Ben

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



__
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] Meeting notes 24 March 2015

2015-03-24 Thread Colleen Murphy

Our meeting minutes from today are here:

http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-03-24-14.59.html

We discussed electing a PTL, and will be following up soon to start a
deeper discussion on the mailing lists.

We'd like to start dedicating time for launchpad bug triage and review
triage at the end of meetings, if time allows. If there are specific
modules that should get attention, please submit them in the agenda.
Otherwise we'd like people to be able to drop in and discuss reviews and
bugs that need special attention. As Hunter put it, If there are
high-profile reviews or bugs that we can't reach a conclusion on during the
normal week, those are often the target of discussion during triage.

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

[openstack-dev] [Neutron] VLAN trunking network for NFV

2015-03-24 Thread Daniele Casini


Hi all:

in reference to the following specification about the creation of VLAN 
trunking network for NFV


https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst

I would like to better understand how the tagged traffic will be 
realized. In order to explain myself, I report the following use case:


A VNF is deployed in one VM, which has a trunk port carrying traffic for 
two VLANs over a single link able to transport more than one VLAN 
through a single integration-bridge (br-int) port. So, How does br-int 
manage the VLAN-ID? In other words, what are the action performed by the 
br-int when a VM forwards traffic to another host?
Does it put an additional tag or replace the existing one keeping the 
match with a table or something like that?


Thank you very much.

Daniele


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

[openstack-dev] [neutron] FF and our march towards the RC

2015-03-24 Thread Kyle Mestery

Folks:

I've gone through the BPs granted an FFE and I have our RC-1 setup now [1].
Please note that the BPs in there all need to merge by the dates specified
in the BP in Launchpad. Most are by next Tuesday, March 31. But the LBaaS
drivers need to go in by Friday. If these BPs don't land by then, they'll
be out of Kilo. We need a solid 2 weeks to work on bugs that crop up as
we're testing Neutron Kilo.

I'll be working the bug list next. If you feel a bug should be a release
candidate, target it to RC1 for now.

Core Reviewers: Please be cautious about merging code at this point. When
in doubt, find me in #openstack-neutron.

Thanks!
Kyle

[1] https://launchpad.net/neutron/+milestone/kilo-rc1
__
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.messaging][zeromq] 'Subgroup' for broker-less ZeroMQ driver

2015-03-24 Thread Davanum Srinivas

+1 to keep it together.

-- dims

On Tue, Mar 24, 2015 at 12:17 PM, Flavio Percoco fla...@redhat.com wrote:
 On 24/03/15 11:03 -0500, Ben Nemec wrote:

 On 03/24/2015 10:31 AM, Li Ma wrote:

 On Mon, Mar 23, 2015 at 9:24 PM, Doug Hellmann d...@doughellmann.com
 wrote:

 The goal we set at the Kilo summit was to have a group of people
 interested in zmq start contributing to the driver, and I had hoped to
 the library overall. How do we feel that is going?


 That sounds great. I hope so.

 One way to create a separate group to manage the zmq driver is to move
 it to a separate repository. Is the internal API for messaging drivers
 stable enough to do that?


 Actually I'm not intended to move it to a separate repository. I just
 want to make sure if it is possible to make a fixed online meeting for
 zmq driver.


 And personally I'd prefer not to split the repo.  I'd rather explore the
 idea of driver maintainers whose +1 on driver code counts as +2, like we
 had/have with incubator.  Splitting the repo brings up some sticky
 issues with requirements syncs and such.  I'd like to think that with
 only three different drivers we don't need the overhead of managing
 separate repos, but maybe I'm being optimistic. :-)

 Kind of off topic since that's not what is being proposed here, but two
 different people have mentioned it so I wanted to note my preference in
 case it comes up again.


 +1 I don't think this needs to be split if the only thing needed is
 some extra grants. However, this is not to be forgotten in the long
 run where more complex scenarious may appear.

 Cheers,
 Flavio

 --
 @flaper87
 Flavio Percoco

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




-- 
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] [Neutron] VLAN trunking network for NFV

2015-03-24 Thread Armando M.

From spec [1], I read:


   - Of the core drivers, the VLAN and OVS drivers will be marked as not
   supporting VLAN transparent networks and the LB, VXLAN and GRE drivers will
   be marked as supporting VLAN transparent networks. Other drivers will have
   legacy behaviour.

I can't seem to find in the code where this is implemented though. Can you
elaborate?

This may be besides the point, but I really clash with the idea that we
provide a reference implementation on something we don't have CI for...for
that reason, I am starting to become really wary of the shape this has been
merged in. Let's hope we tie the appropriate loose ends in the next couple
of days, otherwise we're left with no other option than pulling this out of
Kilo.

A

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html





On 24 March 2015 at 11:17, Ian Wells ijw.ubu...@cack.org.uk wrote:

 That spec ensures that you can tell what the plugin is doing.  You can ask
 for a VLAN transparent network, but the cloud may tell you it can't make
 one.

 The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the
 spec you're referring to doesn't change that.  The spec does ensure that if
 you try and create a VLAN trunk on a cloud that uses the OVS driver, you'll
 be told you can't.  in the future, the OVS driver can be fixed, but that's
 how things stand at present.  Fixing the OVS driver really involves getting
 in at the OVS flow level - can be done, but we started with the basics.

 If you want to use a VLAN trunk using the current code, I recommend VXLAN
 or GRE along with the Linuxbridge driver, both of which support VLAN
 transparent networking.  If they're configured and you ask for a VLAN trunk
 you'll be told you got one.
 --
 Ian.


 On 24 March 2015 at 09:43, Daniele Casini daniele.cas...@dektech.com.au
 wrote:

 Hi all:

 in reference to the following specification about the creation of VLAN
 trunking network for NFV

 https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst

 I would like to better understand how the tagged traffic will be
 realized. In order to explain myself, I report the following use case:

 A VNF is deployed in one VM, which has a trunk port carrying traffic for
 two VLANs over a single link able to transport more than one VLAN through a
 single integration-bridge (br-int) port. So, How does br-int manage the
 VLAN-ID? In other words, what are the action performed by the br-int when a
 VM forwards traffic to another host?
 Does it put an additional tag or replace the existing one keeping the
 match with a table or something like that?

 Thank you very much.

 Daniele


 
 __
 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] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

One other item I’d like to bring up.

While Nova and Neutron are well distributed around the globe and have Core 
Reviewers on IRC in the Asia daytime, some other projects are not so well 
distributed as yet.  A problem I noticed a number of times is that an Asia 
based developer will post to the mailing list to get some attention for  
his/her patch.  This is frowned upon in the community, but when there are few 
to no Core Reviewers in IRC, getting that first core review can be difficult.  
Emailing the PTL is something I’m sure the PTLs would like to limit as they are 
already swamped.  So, how do we get timely first core review of patches in 
areas of the world where Core presence in IRC is slim to none?

I can think of a few options but they don’t seem great:

· A filter for dashboards that flags reviews with multiple +1s and no 
core along with a commitment of the Core team to perform a review within x 
number of days

· A separate mailing list for project review requests

· Somehow queueing requests in the IRC channel so that offline 
developers can easily find review requests when looking at channel logs

· ???

Solving this issue could help not just Third Party developers, but all of 
OpenStack and make the community more inviting to Asian and Australian (and 
maybe European and African) developers.

--Rocky

From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Monday, March 23, 2015 14:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
[cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

I’d like to suggest that the myriad wiki pages and spreadsheets for Third Party 
CI also be consolidated to a more manageable count.  Just looking for 
maintainers contact, you can find information (often conflicting) in 
Stackalytics, on the ThirdPartyDrivers page, on the Cinder PTL’s google doc and 
who knows where else for the Neutron maintainers.  Even finding which tests to 
run takes linking through a number of Cinder wiki pages.

The teams have done a great job documenting a process that started out as lore, 
but I think the beginning of L would be a great time to revisit and reorganize 
the documentation for clarity, conciseness and single locations (version 
controlled) of critical information.

--Rocky

From: Patrick East [mailto:patrick.e...@purestorage.com]
Sent: Monday, March 23, 2015 14:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
[cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Mon, Mar 23, 2015 at 12:59 PM, Stefano Maffulli 
stef...@openstack.orgmailto:stef...@openstack.org wrote:
On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:
 We've been talking about CI's for a year. We started talking about CI 
 deadlines
 in August. If you post a driver for Kilo, it was communicated that you're
 required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
 should've been known by your engineers regardless of when you submitted your
 driver.

Let's work to fix the CI bits for Liberty and beyond. I have the feeling
that despite your best effort to communicate deadlines, some quite
visible failure has happened.

I think the only failure is on the side of any driver maintainers who did not 
make the deadlines. From my perspective (as one of the driver maintainers who 
did setup a CI system and a developer working on Cinder) this whole process has 
been a success. The test coverage has sky rocketed for Cinder, driver 
maintainers are forced to be a bit more active in the community, and the code 
base (in theory) no longer has volume drivers in tree that we don't know if 
they actually work or not. This is, in my opinion, a huge win for the project.

You've been clear about Cinder's deadlines, I've been trying to add them
also to the weekly newsletter, too.

To the people whose drivers don't have their CI completed in time: what
do you suggest should change so that you won't miss the deadlines in the
future? How should the processes and tool be different so you'll be
successful with your OpenStack-based products?

For anyone who struggled with getting a CI system operational there are 
numerous resources at your disposal (all of which have been advertised in 
Cinder meetings and the #openstack-cinder IRC channel). There are three 
meetings every week where you can get help setting them up [1]. There are a few 
different Cinder developers who have set up their own CI systems and shared 
code/instructions [2][3]. I have seen those same devs supporting them via IRC 
and have enabled several other companies to successfully use their tools. 
Between these resources I don't think anyone who has actually showed up at the 
meetings, asked for help, and make a good faith effort to keep everyone in the 
loop and show progress

Re: [openstack-dev] [Ceilometer] Meters vs. Metrics

2015-03-24 Thread gordon chung

 Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we 
 should really stick to that convention.
agreed, i just wanted to mention the inconsistencies as they exist today.

to play devil's advocate, the reason i lean more to using 'metric' is that it's 
arguably more widely used (see: documentation for most tsdb, measurements data, 
CADF, etc...). if we were ever to make a change, Gnocchi would be a good place. 
that said, if everyone is acclimated to 'meters' we might as well just keep it.

i cut this out original email and forgot to add it back in but can you create a 
bug in openstack-manual to track this as well. 

cheers,
gord


From: tim.b...@cern.ch
To: openstack-dev@lists.openstack.org
Date: Tue, 24 Mar 2015 18:43:46 +
Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics









Can we keep it consistent ? The APIs have meter in them, so do the CLIs so we 
should really stick to that convention.
 
If Gnocchi is using metrics, I feel it should change to use meters or a V3 API 
proposed that changes it all.

 
Projects and Tenants still cause such massive confusion for the end user, let’s 
not do it again. Saying they are equivalent does not
 stop the confusion and support effort when people say that the form allows 
them to create a project but they want a tenant.
 
Tim
 
 



From: gordon chung [mailto:g...@live.ca]


Sent: 24 March 2015 18:41

To: OpenStack Development Mailing List not for usage questions

Subject: Re: [openstack-dev] [Ceilometer] Meters vs. Metrics


 

tbh, i've been using them interchangeably -- i don't know if they are logically 
different. i believe gnocchi uses 'metric' term while current api uses 'meter' 
so
 we don't really have a common usage in api either. if i were to choose one, 
i'd lean more to using 'metric'.



cheers,

gord





 Date: Tue, 24 Mar 2015 17:43:51 +0800

 From: edwin.z...@intel.com

 To: openstack-dev@lists.openstack.org

 Subject: [openstack-dev] [Ceilometer] Meters vs. Metrics

 

 All,

 I observed various meters and metrics with almost same meaning in 
 telemetry


 part of admin-guild-cloud.

 

 Just curious about the minor difference. If they are interchangeable, we can 

 pick up one for confusion.

 

 

 

 Best Rgds,

 Edwin

 

 __

 OpenStack Development Mailing List (not for usage questions)

 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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







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

Re: [openstack-dev] [nova] Updating 'scheduled_at' field of nova instances in the database.

2015-03-24 Thread Chris Friesen


On 03/24/2015 12:27 AM, Deepak Shetty wrote:


I am _not_ nova expert, but iiuc, a VM is scheduled
once and changing the host as part of migration isn't scheduling, but i could be
wrong too.


Not sure I agree.  Any time that a VM could be placed on a different host the 
scheduler could be involved, no?


So cold migration, live migration, resize, rebuild, or evacuate could all 
involve a scheduling event.


Chris

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

Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin

2015-03-24 Thread Ian Wienand

On 03/24/2015 03:17 PM, Deepak Shetty wrote:
 For eg: Look at [1]
 [1] 
 https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings

 I would like ability to change these while I use the enable_plugin
 apporach to setup devstack w/ GlusterFS per my local glusterfs setup

So I think the plugin should do

CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}

i.e. provide a default only if the variable is unset.

This seems like one of those traps for new players and is one
concern I have with devstack plugins -- that authors keep having to
find out lessons learned independently.  I have added a note on this
to the documentation in [1].

-i

[1] https://review.openstack.org/#/c/167375/

__
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] zero downtime conf/kilo

2015-03-24 Thread Nikhil Komawar

Thanks for your (everyone involved) effort on this!

Do we have documented bugs for getting these patches merged? We're in a RC 
window so better to have explicit indication (possibly using bugs) of what's 
going; this would help the core reviewers to verify and adhere to the freeze 
guidelines.

Please note that we're going to have to tag them as kilo-rc-potential unless 
something is a blocker for Kilo. Also, bringing them up in a meeting should 
work too.

Thanks,
-Nikhil


From: stuart.mcla...@hp.com stuart.mcla...@hp.com
Sent: Tuesday, March 24, 2015 2:31 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] zero downtime conf/kilo

All,

The main zero downtime config patch has merged (thanks to everyone, especially 
Abhishek, for their help).

There's a couple of small, follow on corner case patches, that, eg ensure a 
config change to logging (INFO-DEBUG)
can be picked up dynamically.

Are we planning/hoping to merge them also? (I think it makes a better story 
than the current partial support, and could see kilo bugs
of the 'I changed tcp_keepalive and it wasn't picked up' or 'I changed the log 
level and it wasn't picked up' coming in.)

Thanks,

-Stuart

__
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] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Bryan Sullivan

Hi,
I have a question about where to find the complete set 
of currently supported data drivers (with table/row details) for Congress. 
The info at 
http://congress.readthedocs.org/en/latest/cloudservices.html#drivers seems to 
cover only Nova and Neutron.  I'm sure that I can pull this info from the 
source at 
https://github.com/stackforge/congress/tree/master/congress/datasources but I 
was looking for any documentation on the current state of that code's design. 
The existing blueprints (e.g. at https://github.com/stackforge/congress-specs) 
do not go into this detail AFAICT.

Also, since I'm looking into how the current supported Congress tables will 
support use cases of the OPNFV Copper project [1], it will be also helpful to 
know where I would look for the set of potential policy-related data items 
inside OpenStack docs/code for the various components. If I find a gap against 
a use case, I would want to be able to specify related patches (e.g. where data 
source driver extensions should get the additional data) so I need to know 
where the data comes from (and what's available) inside OpenStack.

[1] https://wiki.opnfv.org/copper/use_cases

Thanks for your help!
Bryan





  __
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] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-24 Thread Assaf Muller

Note that https://review.openstack.org/#/c/166888/ has been merged.
This means that the option has been deprecated for K and will be
removed in L. Anyone using the non-default value of False will be looking
at errors in his logs.

- Original Message -
 
 
 On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
  I see you point Van,
 
  In the other hand, removing it, cleans up lot of conditional code parts
  (moving parts at the other side),
  and also the non-netns case is not tested by upstream CI, AFAIK, so it
  could be broken anytime
  and we would not notice it.
 
 
 
  Miguel Ángel Ajo
 
  On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
 
  I think there are valid reasons to not use namespaces:
 
* Fewer moving parts == less can potentialy fail
* Troubleshooting is easier due to less places to look / need no
  familiarity with namespaces  tools
* If I remember correctly setting up a namespace can get really
  slow when you have a lot of them on a single machine
 
 
   IMHO, those shouldn’t be valid reasons anymore, since they were due
   iproute, or sudo issues
   that have been corrected long ago, and all distros installing neutron
   are supporting netns at this
 
  Well, you exactly made my point:
  There is lots that can and will go wrong with more moving parts.
  That they are fixed at the moment does not mean that there will not be
  a new bug in the future…
 
  Cheers,
  Robert van Leeuwen
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
  mailto:openstack-operat...@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 
  __
  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
 
 
 FWIW we were doing CI without namespaces before Kilo simply due to RHEL
 6.5 not having the support w/o a kernel patch.
 
 Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
 has namespace support so it's no longer an issue for us.
 
 --
 
 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


__
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 Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Asselin, Ramy

Changing the topic.

Mike Perez did include a Cinder Review Inbox link on the main Cinder Wiki page.
https://wiki.openstack.org/wiki/Cinder#Resources

Not sure how many people/cores use that link but that could be a step towards 
what you’re asking for.
The query should probably be proposed to 
http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards

Ramy


From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Tuesday, March 24, 2015 12:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
[cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

One other item I’d like to bring up.

While Nova and Neutron are well distributed around the globe and have Core 
Reviewers on IRC in the Asia daytime, some other projects are not so well 
distributed as yet.  A problem I noticed a number of times is that an Asia 
based developer will post to the mailing list to get some attention for  
his/her patch.  This is frowned upon in the community, but when there are few 
to no Core Reviewers in IRC, getting that first core review can be difficult.  
Emailing the PTL is something I’m sure the PTLs would like to limit as they are 
already swamped.  So, how do we get timely first core review of patches in 
areas of the world where Core presence in IRC is slim to none?

I can think of a few options but they don’t seem great:

· A filter for dashboards that flags reviews with multiple +1s and no 
core along with a commitment of the Core team to perform a review within x 
number of days

· A separate mailing list for project review requests

· Somehow queueing requests in the IRC channel so that offline 
developers can easily find review requests when looking at channel logs

· ???

Solving this issue could help not just Third Party developers, but all of 
OpenStack and make the community more inviting to Asian and Australian (and 
maybe European and African) developers.

--Rocky

From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Monday, March 23, 2015 14:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
[cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

I’d like to suggest that the myriad wiki pages and spreadsheets for Third Party 
CI also be consolidated to a more manageable count.  Just looking for 
maintainers contact, you can find information (often conflicting) in 
Stackalytics, on the ThirdPartyDrivers page, on the Cinder PTL’s google doc and 
who knows where else for the Neutron maintainers.  Even finding which tests to 
run takes linking through a number of Cinder wiki pages.

The teams have done a great job documenting a process that started out as lore, 
but I think the beginning of L would be a great time to revisit and reorganize 
the documentation for clarity, conciseness and single locations (version 
controlled) of critical information.

--Rocky

From: Patrick East [mailto:patrick.e...@purestorage.com]
Sent: Monday, March 23, 2015 14:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
[cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Mon, Mar 23, 2015 at 12:59 PM, Stefano Maffulli 
stef...@openstack.orgmailto:stef...@openstack.org wrote:
On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:
 We've been talking about CI's for a year. We started talking about CI 
 deadlines
 in August. If you post a driver for Kilo, it was communicated that you're
 required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
 should've been known by your engineers regardless of when you submitted your
 driver.

Let's work to fix the CI bits for Liberty and beyond. I have the feeling
that despite your best effort to communicate deadlines, some quite
visible failure has happened.

I think the only failure is on the side of any driver maintainers who did not 
make the deadlines. From my perspective (as one of the driver maintainers who 
did setup a CI system and a developer working on Cinder) this whole process has 
been a success. The test coverage has sky rocketed for Cinder, driver 
maintainers are forced to be a bit more active in the community, and the code 
base (in theory) no longer has volume drivers in tree that we don't know if 
they actually work or not. This is, in my opinion, a huge win for the project.

You've been clear about Cinder's deadlines, I've been trying to add them
also to the weekly newsletter, too.

To the people whose drivers don't have their CI completed in time: what
do you suggest should change so that you won't miss the deadlines in the
future? How should the processes and tool be different so you'll be
successful with your OpenStack-based products?

For anyone who struggled

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Alex Yip

Hi Bryan,

The drive source code is the best documentation that describes the table and 
row level? detail.

The translator description in the source code sums up the tables an drivers in 
a succinct way.  If you need any additional clarification, let me know.

 - Alex



From: Bryan Sullivan bls...@hotmail.com
Sent: Tuesday, March 24, 2015 12:13 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

Hi, I have a question about where to find the complete set of currently 
supported data drivers (with table/row details) for Congress. The info at 
http://congress.readthedocs.org/en/latest/cloudservices.html#drivershttps://urldefense.proofpoint.com/v2/url?u=http-3A__congress.readthedocs.org_en_latest_cloudservices.html-23driversd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=djA1lFdIf0--GIJ_8gr44Qm=DAMyKamIxt_S7FwDt9ft5eTL0Tz_gZ5KyQVueLiVGxAs=nCnmgLZEB3103MWKkYaVuS4Cnhg8xLNbeoul185--wAe=
 seems to cover only Nova and Neutron.  I'm sure that I can pull this info from 
the source at 
https://github.com/stackforge/congress/tree/master/congress/datasourceshttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_congress_tree_master_congress_datasourcesd=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=djA1lFdIf0--GIJ_8gr44Qm=DAMyKamIxt_S7FwDt9ft5eTL0Tz_gZ5KyQVueLiVGxAs=GH2z3O0oq8AZ8EznJOgF7sLtpRrOkDZdWqxQ-X2X6nse=
 but I was looking for any documentation on the current state of that code's 
design. The existing blueprints (e.g. at 
https://github.com/stackforge/congress-specs)https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_congress-2Dspecs-29d=AwMFAwc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=djA1lFdIf0--GIJ_8gr44Qm=DAMyKamIxt_S7FwDt9ft5eTL0Tz_gZ5KyQVueLiVGxAs=0Qe87C5V3-MiQMxtRNs8Cps698pLOve9ee1BRzKskOUe=
 do not go into this detail AFAICT.

Also, since I'm looking into how the current supported Congress tables will 
support use cases of the OPNFV Copper project [1], it will be also helpful to 
know where I would look for the set of potential policy-related data items 
inside OpenStack docs/code for the various components. If I find a gap against 
a use case, I would want to be able to specify related patches (e.g. where data 
source driver extensions should get the additional data) so I need to know 
where the data comes from (and what's available) inside OpenStack.

[1] https://wiki.opnfv.org/copper/use_cases

Thanks for your help!
Bryan





__
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] [Ceilometer]Add hardware pollster of memory buffer and cache

2015-03-24 Thread Luo Gangyi

Hi guys,


I have submit a blueprint of adding hardware memory buffer and cache pollster.‍


Anyone interested in it, Please review 
https://blueprints.launchpad.net/ceilometer/+spec/hardware-memory-buffer-and-cache-metrics,‍


Thanks All.
--
Luo gangyiluogan...@chinamobile.com



 




-- Original --
From:  gordon chung;g...@live.ca;
Date:  Sat, Mar 21, 2015 04:02 AM
To:  OpenStack Development Mailing List not for usage 
questionsopenstack-dev@lists.openstack.org; 

Subject:  Re: [openstack-dev] [Ceilometer]Add hardware pollster of memorybuffer 
and cache



 this seems reasonable... this might fall into same category ironic generated 
metrics (and any other source that has their own defined list of metrics beyond 
ceilometer's list). there was discussion on how to properly handle these cases 
[1][2]

[1] 
http://eavesdrop.openstack.org/meetings/ceilometer/2015/ceilometer.2015-03-05-15.01.log.html
[2] https://review.openstack.org/#/c/130359/

cheers,
gord



From: lgy...@foxmail.com
To: openstack-dev@lists.openstack.org
Date: Thu, 19 Mar 2015 16:44:20 +0800
Subject: [openstack-dev] [Ceilometer]Add hardware pollster of memory buffer 
and cache

Hello everyone,


I am using Ceilometer to monitor both physical servers and virtutal machines in 
IAAS.
And I found current Ceilometer only support 4 memory oid of SNMP:
_memory_total_oid = 1.3.6.1.4.1.2021.4.5.0
_memory_avail_real_oid = 1.3.6.1.4.1.2021.4.6.0
_memory_total_swap_oid = 1.3.6.1.4.1.2021.4.3.0
_memory_avail_swap_oid = 1.3.6.1.4.1.2021.4.4.0‍



But in practice, memory cache and buffer are also very useful infomation.


So I'd like to add two hardware pollster, MemoryCachePollster and 
MemoryBufferPollster.‍‍


And I want to know is there anyone else insterested in it and should I submit 
blueprint on launchpad?


Thanks.
--
Luo gangyiluogan...@chinamobile.com



 

__ 
OpenStack Development Mailing List (not for usage questions) Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack 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] Updating 'scheduled_at' field of nova instances in the database.

2015-03-24 Thread Deepak Shetty

On Tue, Mar 24, 2015 at 11:57 AM, Deepak Shetty dpkshe...@gmail.com wrote:



 On Tue, Mar 24, 2015 at 10:58 AM, Deepthi Dharwar 
 deep...@linux.vnet.ibm.com wrote:

 On 03/23/2015 09:00 PM, Jay Pipes wrote:
  On Mon, Mar 23, 2015 at 11:18:28AM +0530, Deepthi Dharwar wrote:
  All the VM information is stored in the instances table.
  This includes all the time related field like scheduled_at,
 launched_at etc.
 
  After upgrading to Juno, I have noticed that my 'scheduled_at' field
  is not getting reflected at all in the database. I do see my VMs
  being spawned and running just fine. However, the 'launched_at' time
  does get reflected rightly.
 
 
  MariaDB [nova] select created_at, deleted_at, host,scheduled_at,
 launched_at from instances;
 
 +-+-+---+--+-+
  | created_at  | deleted_at  | host  |
 scheduled_at | launched_at |
 
 +-+-+---+--+-+
  | 2015-03-09 20:00:41 | 2015-03-10 17:12:11 | localhost |
 NULL | 2015-03-09 20:01:30 |
  | 2015-03-11 05:53:13 | NULL| localhost
   | NULL | 2015-03-18 19:48:12 |
 
 
  Can anyone let me know if this is a genuine issue or have there been
  a recent change in regard to updating this field ?
 
  I am basically trying to find as to how long a particular VM is
 running on a given host.
  I was using the current time - scheduled time for the same.
  Is there a better way to get this value ?
 
  Use current_time - launched_at.

 'launched_at' will give me the time a particular VM came into being.
 In a scenario where the VM was launched on host H1, later migrated on to
 a different host H2, 'launched_at' will not give the time the VM
 has been running on host H2, where as 'scheduled_at' would have
 addressed this issue or will it ?


 Per the code , patch @ https://review.openstack.org/#/c/143725/2 removed
 scheduled_at
 since the function was no longer used. Googling i couldn't find more info
 on the history behind
 why these 2 fields were there to begin with.

 I am _not_ nova expert, but iiuc, a VM is scheduled
 once and changing the host as part of migration isn't scheduling, but i
 could be wrong too.

 Since your requirement is to find the time a VM lived on a host, as long
 as launched_at is updated
 post migration, it should suffice i feel ?


FWIW, In nova/compute/manager.py line 4036 is where migration ends and line
4042 is where
the launched_at is updated, post migration.

HTH

thanx,
deepak
__
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] Updating 'scheduled_at' field of nova instances in the database.

2015-03-24 Thread Deepak Shetty

On Tue, Mar 24, 2015 at 10:58 AM, Deepthi Dharwar 
deep...@linux.vnet.ibm.com wrote:

 On 03/23/2015 09:00 PM, Jay Pipes wrote:
  On Mon, Mar 23, 2015 at 11:18:28AM +0530, Deepthi Dharwar wrote:
  All the VM information is stored in the instances table.
  This includes all the time related field like scheduled_at, launched_at
 etc.
 
  After upgrading to Juno, I have noticed that my 'scheduled_at' field
  is not getting reflected at all in the database. I do see my VMs
  being spawned and running just fine. However, the 'launched_at' time
  does get reflected rightly.
 
 
  MariaDB [nova] select created_at, deleted_at, host,scheduled_at,
 launched_at from instances;
 
 +-+-+---+--+-+
  | created_at  | deleted_at  | host  |
 scheduled_at | launched_at |
 
 +-+-+---+--+-+
  | 2015-03-09 20:00:41 | 2015-03-10 17:12:11 | localhost |
 NULL | 2015-03-09 20:01:30 |
  | 2015-03-11 05:53:13 | NULL| localhost
   | NULL | 2015-03-18 19:48:12 |
 
 
  Can anyone let me know if this is a genuine issue or have there been
  a recent change in regard to updating this field ?
 
  I am basically trying to find as to how long a particular VM is running
 on a given host.
  I was using the current time - scheduled time for the same.
  Is there a better way to get this value ?
 
  Use current_time - launched_at.

 'launched_at' will give me the time a particular VM came into being.
 In a scenario where the VM was launched on host H1, later migrated on to
 a different host H2, 'launched_at' will not give the time the VM
 has been running on host H2, where as 'scheduled_at' would have
 addressed this issue or will it ?


Per the code , patch @ https://review.openstack.org/#/c/143725/2 removed
scheduled_at
since the function was no longer used. Googling i couldn't find more info
on the history behind
why these 2 fields were there to begin with.

I am _not_ nova expert, but iiuc, a VM is scheduled
once and changing the host as part of migration isn't scheduling, but i
could be wrong too.

Since your requirement is to find the time a VM lived on a host, as long as
launched_at is updated
post migration, it should suffice i feel ?

thanx,
deepak
__
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 Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Excerpts from Mark McClain's message of 2015-03-24 10:25:31 -0400:
 
 Echoing both Thierry and John.  I support Mike’s decision to enforce the 
 requirement. Maintaining drivers in the tree comes with responsibilities to 
 the community and 3rd party CI is one of the them.  Mike enforcing this 
 requirement was the right action even if a hard one to take.
 
 mark

Indeed. The deadlines were communicated clearly, and frequently.
Making phone calls to reach out to contributors for issues like
this is exceptional.

Doug

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

Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers

2015-03-24 Thread Bryan Sullivan




Thanks for clarifying, Tim (and Alex for the other response).

Since I have to understand the code anyway going to the drivers for current 
info is reasonable.

Can I derive from your statement One of Congress’s goals is to make any data 
available via an API call to policy-related that Congress already exposes (in 
Congress tables) most/all data available through OpenStack component APIs? That 
would save me digging through the OpenStack code as well.

From: thinri...@vmware.com
To: openstack-dev@lists.openstack.org
Date: Tue, 24 Mar 2015 19:57:26 +
Subject: Re: [openstack-dev] [Congress] Info on Currently Supported Data Drivers






Hi Bryan,



Inline.




On Mar 24, 2015, at 12:13 PM, Bryan Sullivan bls...@hotmail.com wrote:



Hi, I have a question about where to find the complete set of currently 
supported data drivers (with table/row details) for Congress. The info at
http://congress.readthedocs.org/en/latest/cloudservices.html#drivers
seems to cover only Nova and Neutron.  I'm sure that I can pull this info from 
the source at

https://github.com/stackforge/congress/tree/master/congress/datasources but I 
was looking for any documentation on the current state of that code's design. 
The existing blueprints (e.g. at

https://github.com/stackforge/congress-specs) do not go into this detail AFAICT.










I’d definitely just do a directory listing on the source code.  Syncing the 
docs is something we do before a major release.  Things are just changing too 
quickly to do anything else. 






Also, since I'm looking into how the current supported Congress tables will 
support use cases of the OPNFV Copper project [1], it will be also helpful to 
know where I would look for the set of potential policy-related data items 
inside
 OpenStack docs/code for the various components. If I find a gap against a use 
case, I would want to be able to specify related patches (e.g. where data 
source driver extensions should get the additional data) so I need to know 
where the data comes from (and
 what's available) inside OpenStack.










One of Congress’s goals is to make any data available via an API call to 
policy-related.  So anything the API calls of OpenStack returns are reasonable 
candidates for writing policy over.



Tim  





[1] 
https://wiki.opnfv.org/copper/use_cases



Thanks for your help!

Bryan















__

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] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On 19:38 Tue 24 Mar , Asselin, Ramy wrote:
 Changing the topic.
 
 Mike Perez did include a Cinder Review Inbox link on the main Cinder Wiki
 page.
 https://wiki.openstack.org/wiki/Cinder#Resources
 
 Not sure how many people/cores use that link but that could be a step towards
 what you’re asking for.
 The query should probably be proposed to 
 http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards
 
 Ramy
 
 
 From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
 Sent: Tuesday, March 24, 2015 12:02 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: 
 [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))
 
 One other item I’d like to bring up.
 
 While Nova and Neutron are well distributed around the globe and have Core 
 Reviewers on IRC in the Asia daytime, some other projects are not so well 
 distributed as yet.  A problem I noticed a number of times is that an Asia 
 based developer will post to the mailing list to get some attention for  
 his/her patch.  This is frowned upon in the community, but when there are 
 few to no Core Reviewers in IRC, getting that first core review can be 
 difficult.  Emailing the PTL is something I’m sure the PTLs would like to 
 limit as they are already swamped.  So, how do we get timely first core 
 review of patches in areas of the world where Core presence in IRC is slim 
 to none?
 
 I can think of a few options but they don’t seem great:
 
 · A filter for dashboards that flags reviews with multiple +1s and 
 no core along with a commitment of the Core team to perform a review within 
 x number of days
 
 · A separate mailing list for project review requests
 
 · Somehow queueing requests in the IRC channel so that offline 
 developers can easily find review requests when looking at channel logs
 
 · ???
 
 Solving this issue could help not just Third Party developers, but all of 
 OpenStack and make the community more inviting to Asian and Australian (and 
 maybe European and African) developers.
 
 --Rocky

Yes thanks Ramy. That's exactly what this dashboard helps with and has existed
since January. I brought it up at the Cinder midcycle meetup, multiple times in
meetings, reviewathons, etc. I was letting it sit and have people try it out
before proposing to see if anyone had feedback. Since it has been sitting for
a while without feedback, I'll go ahead and propose it.

-- 
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] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Arkady_Kanevsky

Dell - Internal Use - Confidential
The link from cinder page to Cinder review inbox  
(https://review.openstack.org/#/dashboard/) from 
https://wiki.openstack.org/wiki/Cinder#Resources is empty.

Link to bugs does work.

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com]
Sent: Tuesday, March 24, 2015 3:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: 
what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers 
(no voting CI))

On 19:38 Tue 24 Mar , Asselin, Ramy wrote:
 Changing the topic.

 Mike Perez did include a Cinder Review Inbox link on the main Cinder
 Wiki page.
 https://wiki.openstack.org/wiki/Cinder#Resources

 Not sure how many people/cores use that link but that could be a step
 towards what you're asking for.
 The query should probably be proposed to
 http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dash
 boards

 Ramy


 From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
 Sent: Tuesday, March 24, 2015 12:02 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was
 Re: [cinder] Request exemption for removal of NetApp FC drivers (no
 voting CI))

 One other item I'd like to bring up.

 While Nova and Neutron are well distributed around the globe and have Core 
 Reviewers on IRC in the Asia daytime, some other projects are not so well 
 distributed as yet. A problem I noticed a number of times is that an Asia 
 based developer will post to the mailing list to get some attention for 
 his/her patch. This is frowned upon in the community, but when there are few 
 to no Core Reviewers in IRC, getting that first core review can be 
 difficult. Emailing the PTL is something I'm sure the PTLs would like to 
 limit as they are already swamped. So, how do we get timely first core 
 review of patches in areas of the world where Core presence in IRC is slim 
 to none?

 I can think of a few options but they don't seem great:

 * A filter for dashboards that flags reviews with multiple +1s and no core 
 along with a commitment of the Core team to perform a review within x number 
 of days

 * A separate mailing list for project review requests

 * Somehow queueing requests in the IRC channel so that offline developers 
 can easily find review requests when looking at channel logs

 * ???

 Solving this issue could help not just Third Party developers, but all of 
 OpenStack and make the community more inviting to Asian and Australian (and 
 maybe European and African) developers.

 --Rocky

Yes thanks Ramy. That's exactly what this dashboard helps with and has existed 
since January. I brought it up at the Cinder midcycle meetup, multiple times in 
meetings, reviewathons, etc. I was letting it sit and have people try it out 
before proposing to see if anyone had feedback. Since it has been sitting for a 
while without feedback, I'll go ahead and propose it.

--
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] [Neutron] Removing udp_port field from 'ml2_vxlan_endpoint' table

2015-03-24 Thread Andreas Scheuring

Mathieu, 
now I'm getting curious, is it possible to combine Linuxbridge and OVS
VXLAN Nodes in the same cloud? 

I thought this does not work as Linuxbridge-vxlan uses multicast for
instances broad- and multicasts (e.g. an arp request), while ovs-vxlan
only does unicast? At least one can specify a vxlan_group, which is a
mulitcast address, for linuxbridge vxlan.


Or is multicasting prohibited by l2_pop driver and the vxlan_group
attribute is not applicable in this case?



-- 
Andreas 
(irc: scheuran)


On Mon, 2015-03-23 at 14:49 +0100, Mathieu Rohon wrote:
 Hi romil,
 
 
 I think the main purpose of this DB field is to maintain the
 compatibility in dataplane between OVS and LinuxBridge which, by
 default, don't use the same UDP port for VXLAN.
 
 It might be useful for a cloud admin which wants to run some nodes
 with LB and some others with OVS.
 
 
 I feel like your patch proposal will enable this scenario if the
 tunnel_update() RPC message gets updated with the UDP port too.
 
 
 
 Mathieu
 
 
 On Mon, Mar 23, 2015 at 11:40 AM, Romil Gupta romilgupt...@gmail.com
 wrote:
 Hello everyone,
 
 
 There is regarding the following bug:
 https://bugs.launchpad.net/neutron/+bug/1373359
 
 
 May I know what is the significance of having the 'udp_port'
 field in the  'ml2_vxlan_endpoints' table in Neutron DB, Do we
 have any plans in future that we could use this field for
 synchronization or any other purpose instead of simply keeping
 it in the DB.
 
 
 The following patchset will fix the bug mentioned above,
 https://review.openstack.org/#/c/153891/
 
 
 But the question still remains the same. Do we need to keep
 this field or we need to remove it? 
 
 
 -- 
 
 Regards,
 Romil 
 
 
 
 
 __
 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] [Keystone][FFE] ECP wrapped assertions

2015-03-24 Thread Marek Denis


Hi,

I strongly support this request.

On 23.03.2015 22:42, Steve Martinelli wrote:
I'd like to request an exemption for the following to go into the Kilo 
release.


This work is crucial for:
-  Keystone to Keystone communication. An ECP wrapped SAML assertion 
will make it much easier for consumers and clients to use the K2K 
feature in Keystone. Currently, a client must take the generated SAML 
response and must prepare the ECP envelope themselves. This should be 
handled by Keystone, and not the clients. The client should be able to 
ask for the ECP wrapped assertion and hand it off to another Keystone.


Why this needs an FFE?
- To properly created an ECP wrapped a SAML assertion, a relay state 
property must be known, (as it's used to compute a value in an ECP 
specific field). This depends on how the service provider has their 
mod_shib configured. We will need to add a new property to the 
keystone resource 'service provider' - the spec change is here: 
https://review.openstack.org/#/c/166086/


Status of the work:
- The patches necessary for this feature already and split into two 
patches. 1) To add a new relay_state_prefix property to the service 
provider resource: https://review.openstack.org/#/c/166078/and 2) to 
actually use this new property in order to generate the ECP assertion: 
https://review.openstack.org/#/c/162866/


Thanks,

Steve Martinelli
OpenStack Keystone Core



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

[openstack-dev] [all] creating stable branches for all libraries, Oslo, client, and other